perm filename COMMON.6[COM,LSP] blob
sn#810559 filedate 1986-02-12 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00659 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00087 00002
C00088 00003 ∂15-Sep-85 1441 MMcM@SCRC-STONY-BROOK.ARPA LAMBDA expression to the SATISFIES type specifier
C00091 00004 ∂16-Sep-85 1115 RAM@C.CS.CMU.EDU structure equality in slisp
C00094 00005 ∂16-Sep-85 1251 REM%IMSSS.#Pup@SU-SCORE.ARPA EQUAL isn't really correct, I agree
C00098 00006 ∂16-Sep-85 1456 hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA compiling anonymous functions
C00101 00007 ∂17-Sep-85 0727 FAHLMAN@C.CS.CMU.EDU compiling anonymous functions
C00108 00008 ∂18-Sep-85 0637 gls@THINK-AQUINAS.ARPA Franz -> Common Lisp
C00111 00009 ∂18-Sep-85 0805 robbins@DEC-HUDSON Modification to LISTEN
C00113 00010 ∂18-Sep-85 0956 FAHLMAN@C.CS.CMU.EDU Modification to LISTEN
C00115 00011 ∂18-Sep-85 1251 robbins@DEC-HUDSON Concatenated Stream Query
C00117 00012 ∂18-Sep-85 1311 FAHLMAN@C.CS.CMU.EDU Concatenated Stream Query
C00119 00013 ∂18-Sep-85 1318 @MIT-REAGAN.ARPA:Soley@MIT-MC.ARPA Concatenated Stream Query
C00122 00014 ∂18-Sep-85 1415 gls@THINK-AQUINAS.ARPA Concatenated Stream Query
C00124 00015 ∂18-Sep-85 1516 wagner@GSWD-VMS Erratum
C00125 00016 ∂18-Sep-85 1822 MMcM@SCRC-STONY-BROOK.ARPA Modification to LISTEN
C00128 00017 ∂19-Sep-85 0702 gls@THINK-AQUINAS.ARPA Erratum
C00130 00018 ∂19-Sep-85 1626 MLY%MIT-OZ@MIT-MC.ARPA Returning additional values from advertised functions
C00134 00019 ∂19-Sep-85 1758 bobrow.pa@Xerox.ARPA Arguments and values to get.
C00136 00020 ∂19-Sep-85 1819 FAHLMAN@C.CS.CMU.EDU Arguments and values to get.
C00139 00021 ∂20-Sep-85 0649 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Erratum on p.107Subject:
C00141 00022 ∂20-Sep-85 0651 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA erratum: logic error on p.125
C00143 00023 ∂20-Sep-85 0709 KMP@SCRC-STONY-BROOK.ARPA Arguments and values to get.
C00147 00024 ∂20-Sep-85 0737 DLW@SCRC-STONY-BROOK.ARPA erratum: logic error on p.125
C00150 00025 ∂20-Sep-85 0741 DLW@SCRC-STONY-BROOK.ARPA Erratum on p.107Subject:
C00153 00026 ∂20-Sep-85 1215 gls@THINK-AQUINAS.ARPA Erratum on p.107Subject:
C00156 00027 ∂20-Sep-85 1219 gls@THINK-AQUINAS.ARPA erratum: logic error on p.125
C00159 00028 ∂20-Sep-85 1221 gls@THINK-AQUINAS.ARPA erratum: logic error on p.125
C00161 00029 ∂20-Sep-85 1348 mips!escargot.earl@glacier Arguments and values to get.
C00163 00030 ∂20-Sep-85 1702 FAHLMAN@C.CS.CMU.EDU EQUAL isn't really correct, I agree
C00166 00031 ∂20-Sep-85 2312 GSB@MIT-MC.ARPA Modification to LISTEN
C00168 00032 ∂21-Sep-85 0729 robbins@DEC-HUDSON LISTEN Proposal
C00170 00033 ∂21-Sep-85 1350 edsel!jim@su-navajo.arpa listen, etc.
C00175 00034 ∂22-Sep-85 1814 GJC@MIT-MC.ARPA Lisp Test
C00177 00035 ∂22-Sep-85 1846 FAHLMAN@C.CS.CMU.EDU Lisp Test
C00179 00036 ∂22-Sep-85 1848 FAHLMAN@C.CS.CMU.EDU Lisp Test -- oops!
C00181 00037 ∂23-Sep-85 1131 DDYER@SCRC-QUABBIN.ARPA Lisp Test
C00184 00038 ∂23-Sep-85 1425 gls@THINK-AQUINAS.ARPA Public relations: second time around
C00189 00039 ∂24-Sep-85 2129 RPG Meeting
C00193 00040 ∂24-Sep-85 2359 TIM@MIT-MC.ARPA Lisp Test
C00195 00041 ∂25-Sep-85 0946 KESSLER@UTAH-20.ARPA Argument Type Mismatch Errors
C00198 00042 ∂25-Sep-85 1132 smh@mit-ems.ARPA Re: Argument Type Mismatch Errors
C00201 00043 ∂25-Sep-85 1153 smh@mit-ems.ARPA missing function: typep-type-p
C00204 00044 ∂25-Sep-85 1438 gls@THINK-AQUINAS.ARPA Public relations: data so far
C00216 00045 ∂25-Sep-85 1535 JAR@MIT-MC.ARPA Public relations: data so far
C00218 00046 ∂25-Sep-85 1844 Moon@SCRC-STONY-BROOK.ARPA Lisp Test
C00220 00047 ∂25-Sep-85 1845 Moon@SCRC-STONY-BROOK.ARPA Returning additional values from advertised functions
C00222 00048 ∂25-Sep-85 1901 Moon@SCRC-STONY-BROOK.ARPA go and return-from inside unwind-protect cleanup
C00225 00049 ∂25-Sep-85 1914 RAM@C.CS.CMU.EDU Discouraged programming practices
C00227 00050 ∂26-Sep-85 0100 STEINER@BLUE.RUTGERS.EDU More corrections to CLtL
C00229 00051 ∂26-Sep-85 0404 smh@mit-ems.ARPA CLtL ambiguity in trace
C00231 00052 ∂26-Sep-85 0432 bs%hp-mars.csnet@CSNET-RELAY.ARPA disassemble and compile questions
C00235 00053 ∂26-Sep-85 0501 smh@mit-ems.ARPA CLtL error re function special form
C00238 00054 ∂26-Sep-85 0728 gls@THINK-AQUINAS.ARPA Joke
C00240 00055 ∂26-Sep-85 0744 AS%hp-hulk.csnet@CSNET-RELAY.ARPA Re: missing function: typep-type-p
C00242 00056 ∂26-Sep-85 0748 gls@THINK-AQUINAS.ARPA go and return-from inside unwind-protect cleanup
C00246 00057 ∂26-Sep-85 0751 gls@THINK-AQUINAS.ARPA Discouraged programming practices
C00248 00058 ∂26-Sep-85 0758 gls@THINK-AQUINAS.ARPA More corrections to CLtL
C00252 00059 ∂26-Sep-85 0806 gls@THINK-AQUINAS.ARPA CLtL error re function special form
C00257 00060 ∂26-Sep-85 0954 gls@THINK-AQUINAS.ARPA Infinite optimization
C00261 00061 ∂26-Sep-85 1250 DDYER@SCRC-QUABBIN.ARPA Infinite optimization
C00264 00062 ∂26-Sep-85 1455 Moon@SCRC-STONY-BROOK.ARPA go and return-from inside unwind-protect cleanup
C00266 00063 ∂26-Sep-85 1516 Moon@SCRC-STONY-BROOK.ARPA disassemble and compile questions
C00272 00064 ∂27-Sep-85 1512 FAHLMAN@C.CS.CMU.EDU Argument Type Mismatch Errors
C00275 00065 ∂30-Sep-85 1724 bs%hp-mars.csnet@CSNET-RELAY.ARPA Re: disassemble and compile questions
C00279 00066 ∂30-Sep-85 1734 FAHLMAN@C.CS.CMU.EDU disassemble and compile questions
C00281 00067 ∂30-Sep-85 1948 GJC@MIT-MC.ARPA go and return-from inside unwind-protect cleanup
C00283 00068 ∂01-Oct-85 1022 gray@GSWD-VMS UNIX terminal io incompatibility
C00286 00069 ∂01-Oct-85 1106 ANDY@SU-SUSHI.ARPA Re: UNIX terminal io incompatibility
C00288 00070 ∂01-Oct-85 1148 DLW@SCRC-STONY-BROOK.ARPA Re: disassemble and compile questions
C00292 00071 ∂01-Oct-85 1545 GJC@MIT-MC.ARPA UNIX terminal io incompatibility
C00294 00072 ∂01-Oct-85 2333 STEINER@RED.RUTGERS.EDU Another printing bug in CLtL
C00296 00073 ∂02-Oct-85 0808 gls@THINK-AQUINAS.ARPA Another printing bug in CLtL
C00298 00074 ∂02-Oct-85 1505 mips!escargot.earl@glacier Another printing bug in CLtL
C00300 00075 ∂02-Oct-85 1800 @MIT-MC.ARPA:uucp@MIT-CCC
C00304 00076 ∂03-Oct-85 1436 DCP@SCRC-QUABBIN.ARPA Arguments and values to get.
C00306 00077 ∂03-Oct-85 1451 DCP@SCRC-QUABBIN.ARPA Discouraged programming practices
C00309 00078 ∂03-Oct-85 1507 wagner@GSWD-VMS CLtL binding
C00310 00079 ∂03-Oct-85 1910 RAM@C.CS.CMU.EDU Without-Interrupts
C00314 00080 ∂04-Oct-85 1548 DLW@SCRC-STONY-BROOK.ARPA implicit blocks
C00317 00081 ∂07-Oct-85 1054 RPG
C00323 00082 ∂08-Oct-85 0917 OLDMAN@USC-ISI.ARPA UNIX terminal io incompatibility
C00325 00083 ∂09-Oct-85 1018 RPG Response to CL Meeting Announcement
C00326 00084 ∂10-Oct-85 0528 GJC@MIT-MC.ARPA Response to CL Meeting Announcement
C00327 00085 ∂10-Oct-85 1708 isrlist@tove.umd.edu
C00328 00086 ∂10-Oct-85 1726 SCHUMACHER%hp-hulk.csnet@CSNET-RELAY.ARPA pathnames.
C00330 00087 ∂10-Oct-85 1739 DCP@SCRC-STONY-BROOK.ARPA pathnames.
C00332 00088 ∂11-Oct-85 0748 wagner@GSWD-VMS oversight?
C00333 00089 ∂11-Oct-85 1242 Moon@SCRC-STONY-BROOK.ARPA oversight?
C00336 00090 ∂11-Oct-85 1549 hplabs!schumacher%hplabs.csnet@CSNET-RELAY.ARPA Re: pathnames.
C00339 00091 ∂11-Oct-85 2025 Moon@SCRC-STONY-BROOK.ARPA Re: pathnames.
C00344 00092 ∂15-Oct-85 1119 RLB@SCRC-STONY-BROOK.ARPA Re: pathnames.
C00349 00093 ∂15-Oct-85 1247 RWK@SCRC-STONY-BROOK.ARPA Re: pathnames.
C00351 00094 ∂15-Oct-85 1520 GSB@MIT-MC.ARPA SETF of pathname components
C00353 00095 ∂22-Oct-85 1546 greek@DEC-HUDSON WITHOUT-INTERRUPTS
C00354 00096 ∂22-Oct-85 1554 gls@THINK-AQUINAS.ARPA Report on trip to Japan
C00358 00097 ∂22-Oct-85 1908 gls@THINK-AQUINAS.ARPA Report on trip to Japan
C00362 00098 ∂23-Oct-85 0723 BSG@SCRC-YUKON.ARPA WITHOUT-INTERRUPTS
C00365 00099 ∂23-Oct-85 0822 greek@DEC-HUDSON WITHOUT-INTERRUPTS
C00367 00100 ∂23-Oct-85 0947 BSG@SCRC-STONY-BROOK.ARPA WITHOUT-INTERRUPTS
C00371 00101 ∂23-Oct-85 1023 greek@DEC-HUDSON WITHOUT-INTERRUPTS
C00373 00102 ∂23-Oct-85 1030 Moon@SCRC-STONY-BROOK.ARPA WITHOUT-INTERRUPTS
C00377 00103 ∂23-Oct-85 1110 Moon@SCRC-STONY-BROOK.ARPA WITHOUT-INTERRUPTS
C00380 00104 ∂23-Oct-85 1258 greek@DEC-HUDSON WITHOUT-INTERRUPTS
C00382 00105 ∂24-Oct-85 1036 gls@THINK-AQUINAS.ARPA WITHOUT-INTERRUPTS: my last message
C00385 00106 ∂24-Oct-85 1042 GJC@MIT-MC.ARPA WITHOUT-INTERRUPTS
C00388 00107 ∂25-Oct-85 1337 RPG Meeting
C00389 00108 ∂26-Oct-85 1315 RPG Tentative Schedule for the Common Lisp Meeting
C00390 00109 ∂28-Oct-85 0855 masinter.pa@Xerox.ARPA Re: Tentative Schedule for the Common Lisp Meeting
C00391 00110 ∂28-Oct-85 1233 OLDMAN@USC-ISI.ARPA Uniqueness of &rest arguments
C00393 00111 ∂28-Oct-85 1445 gls@THINK-AQUINAS.ARPA Uniqueness of &rest arguments
C00396 00112 ∂28-Oct-85 1711 Moon@SCRC-STONY-BROOK.ARPA Uniqueness of &rest arguments
C00400 00113 ∂28-Oct-85 1715 Moon@SCRC-STONY-BROOK.ARPA Tentative Schedule for the Common Lisp Meeting
C00402 00114 ∂29-Oct-85 1649 hoey@nrl-aic Default scope of references
C00407 00115 ∂30-Oct-85 0545 jeff%aiva.edinburgh.ac.uk@ucl-cs.ARPA Re: Tentative Schedule for the Common Lisp Meeting
C00410 00116 ∂30-Oct-85 0632 GJC@MIT-MC.ARPA Default scope of references
C00413 00117 ∂30-Oct-85 1013 JAR@MIT-MC.ARPA absence of (declare (unspecial ...))
C00414 00118 ∂30-Oct-85 1142 DLW@SCRC-STONY-BROOK.ARPA Default scope of references
C00416 00119 ∂30-Oct-85 1225 RWK@SCRC-YUKON.ARPA Default scope of references
C00421 00120 ∂31-Oct-85 0847 MLY@MIT-MC.ARPA free variable references in interpreter.
C00425 00121 ∂31-Oct-85 0947 FAHLMAN@C.CS.CMU.EDU free variable references in interpreter.
C00428 00122 ∂31-Oct-85 1551 GJC@MIT-MC.ARPA free variable references in interpreter.
C00433 00123 ∂31-Oct-85 1820 FAHLMAN@C.CS.CMU.EDU free variable references in interpreter.
C00438 00124 ∂31-Oct-85 1858 GSB@MIT-MC.ARPA free variable references in interpreter.
C00442 00125 ∂01-Nov-85 0846 gls@THINK-AQUINAS.ARPA free variable references in interpreter.
C00448 00126 ∂01-Nov-85 1136 FAHLMAN@C.CS.CMU.EDU free variable references in interpreter.
C00455 00127 ∂01-Nov-85 1242 shebs%utah-orion@utah-cs.arpa Declaring Functions
C00458 00128 ∂01-Nov-85 1529 DCP@SCRC-STONY-BROOK.ARPA free variable references in interpreter.
C00462 00129 ∂01-Nov-85 1721 FAHLMAN@C.CS.CMU.EDU free variable references in interpreter.
C00465 00130 ∂02-Nov-85 2052 isrlist@tove.umd.edu defvar, defparameter, :unbound
C00467 00131 ∂03-Nov-85 0510 GJC@MIT-MC.ARPA extra features/values
C00468 00132 ∂03-Nov-85 0719 SOLEY@MIT-MC.ARPA defvar, defparameter, :unbound
C00470 00133 ∂03-Nov-85 0724 SOLEY@MIT-MC.ARPA extra features/values
C00473 00134 ∂04-Nov-85 0846 DCP@SCRC-QUABBIN.ARPA free variable references in interpreter.
C00477 00135 ∂04-Nov-85 1022 @MIT-MC.ARPA:Soley@MIT-MC.ARPA free variable references in interpreter.
C00480 00136 ∂04-Nov-85 1022 @MIT-MC.ARPA:Soley@MIT-MC.ARPA free variable references in interpreter.
C00483 00137 ∂04-Nov-85 1240 DLW@SCRC-STONY-BROOK.ARPA defvar, defparameter, :unbound
C00485 00138 ∂04-Nov-85 1447 AS%hp-hulk.csnet@CSNET-RELAY.ARPA functions that return nonstandard extra values
C00487 00139 ∂04-Nov-85 1500 hplabs!perdue%hplabs.csnet@CSNET-RELAY.ARPA Re: free variable references in interpreter.
C00489 00140 ∂04-Nov-85 1703 DCP@SCRC-STONY-BROOK.ARPA functions that return nonstandard extra values
C00492 00141 ∂04-Nov-85 1858 GJC@MIT-MC.ARPA functions that return nonstandard extra values
C00494 00142 ∂04-Nov-85 1925 DLW@SCRC-STONY-BROOK.ARPA Declaring Functions
C00497 00143 ∂04-Nov-85 1934 DLW@SCRC-STONY-BROOK.ARPA functions that return nonstandard extra values
C00499 00144 ∂04-Nov-85 2019 GSB@MIT-MC.ARPA defvar, defparameter, :unbound
C00501 00145 ∂05-Nov-85 0734 DCP@SCRC-STONY-BROOK.ARPA functions that return nonstandard extra values
C00504 00146 ∂05-Nov-85 0941 gls@THINK-AQUINAS.ARPA functions that return nonstandard extra values
C00507 00147 ∂05-Nov-85 0950 gls@THINK-AQUINAS.ARPA defvar, defparameter, :unbound
C00511 00148 ∂05-Nov-85 1154 isrlist@tove.umd.edu defvar, defparameter, :unbound
C00513 00149 ∂05-Nov-85 1213 LOOSEMORE@UTAH-20.ARPA queries about *query-io*
C00515 00150 ∂05-Nov-85 1239 DCP@SCRC-STONY-BROOK.ARPA defvar, defparameter, :unbound
C00519 00151 ∂05-Nov-85 1517 HENRIK@MIT-MC.ARPA queries about *query-io*
C00522 00152 ∂05-Nov-85 1655 LOOSEMORE@UTAH-20.ARPA Re: queries about *query-io*
C00524 00153 ∂06-Nov-85 0400 GJC@MIT-MC.ARPA (GETHASH X Y) ==> (CDR (GETHASH X Y))
C00526 00154 ∂06-Nov-85 0429 GJC@MIT-MC.ARPA functions that return nonstandard extra values
C00530 00155 ∂06-Nov-85 0738 MEEHAN@YALE.ARPA CL erratissimo
C00531 00156 ∂06-Nov-85 0904 mips!escargot.earl@glacier defvar, defparameter, :unbound
C00533 00157 ∂06-Nov-85 0947 gls@THINK-AQUINAS.ARPA CL erratissimo
C00535 00158 ∂08-Nov-85 1646 FAHLMAN@C.CS.CMU.EDU astronaut example on p.313
C00537 00159 ∂08-Nov-85 1648 FAHLMAN@C.CS.CMU.EDU Language spec should be public domain
C00539 00160 ∂08-Nov-85 1649 gls@THINK-AQUINAS.ARPA Common Lisp manual online?
C00541 00161 ∂08-Nov-85 1651 gls@THINK-AQUINAS.ARPA astronaut example on p.313
C00544 00162 ∂08-Nov-85 1705 hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA compiler-let (clarification needed)
C00547 00163 ∂08-Nov-85 2244 PGS%MIT-OZ@MIT-MC.ARPA astronaut example on p.313
C00550 00164 ∂09-Nov-85 1115 DLW@SCRC-STONY-BROOK.ARPA Suggested addition to the index of CLtL
C00552 00165 ∂09-Nov-85 1606 RPG Meeting: The Details
C00558 00166 Common-lisp/su
C00561 00167 ∂10-Nov-85 1828 EVAN@SU-CSLI.ARPA Pointers to vax/unix version
C00563 00168 ∂11-Nov-85 0944 Kahn.pa@Xerox.ARPA RE: Steele's programming style
C00565 00169 ∂18-Nov-85 1331 gls@THINK-AQUINAS.ARPA TYPEP and arrays of (SATISFIES F)
C00568 00170 ∂19-Nov-85 0056 RAM@C.CS.CMU.EDU :Structure-Print and *print-level*
C00570 00171 ∂19-Nov-85 1346 KESSLER@UTAH-20.ARPA Universal Catch
C00572 00172 ∂19-Nov-85 1645 REM@IMSSS CATCH-ALL
C00574 00173 ∂19-Nov-85 1657 RWK@SCRC-YUKON.ARPA Universal Catch
C00577 00174 ∂19-Nov-85 1739 kessler%utah-orion@utah-cs.arpa Re: Universal Catch
C00579 00175 ∂19-Nov-85 1925 GSB@MIT-MC.ARPA catching
C00582 00176 ∂19-Nov-85 1941 @MIT-MC.ARPA:BROOKS@MIT-OZ Re: Universal Catch
C00585 00177 ∂20-Nov-85 0050 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Extra paren in example on p.430
C00587 00178 ∂20-Nov-85 0911 gls@THINK-AQUINAS.ARPA Extra paren in example on p.430
C00589 00179 ∂20-Nov-85 1139 gls@THINK-AQUINAS.ARPA Extra paren in example on p.430
C00591 00180 ∂20-Nov-85 1148 BSG@SCRC-STONY-BROOK.ARPA CATCH-ALL
C00594 00181 ∂20-Nov-85 1417 Moon@SCRC-QUABBIN.ARPA Fill-pointers and sequences
C00597 00182 ∂20-Nov-85 1428 Moon@SCRC-QUABBIN.ARPA Universal Catch
C00600 00183 ∂20-Nov-85 1429 Moon@SCRC-QUABBIN.ARPA CATCH-ALL
C00602 00184 ∂20-Nov-85 1432 Moon@SCRC-QUABBIN.ARPA CATCH-ALL
C00604 00185 ∂20-Nov-85 1729 FAHLMAN@C.CS.CMU.EDU Fill-pointers and sequences
C00608 00186 ∂21-Nov-85 0702 FAHLMAN@C.CS.CMU.EDU :Structure-Print and *print-level*
C00613 00187 ∂21-Nov-85 0741 gls@THINK-AQUINAS.ARPA Fill-pointers and sequences
C00617 00188 ∂21-Nov-85 0844 gls@THINK-AQUINAS.ARPA Fill-pointers and sequences
C00621 00189 ∂21-Nov-85 0846 gls@THINK-AQUINAS.ARPA :Structure-Print and *print-level*
C00624 00190 ∂21-Nov-85 1030 greek%bach.decnet@hudson.dec.com Recursive print & depth abbreviation
C00628 00191 ∂21-Nov-85 1214 hoey@nrl-aic Re: :Structure-Print and *print-level*
C00632 00192 ∂21-Nov-85 1313 greek%bach.decnet@hudson.dec.com Recursive printing.
C00634 00193 ∂21-Nov-85 1324 FAHLMAN@C.CS.CMU.EDU :Structure-Print and *print-level*
C00636 00194 ∂21-Nov-85 1402 greek%bach.decnet@hudson.dec.com Recursive printing.
C00637 00195 ∂21-Nov-85 1703 hoey@nrl-aic Re: Recursive printing.
C00641 00196 ∂21-Nov-85 1913 robbins%bach.decnet@hudson.dec.com Recursive printing.
C00645 00197 ∂22-Nov-85 0738 DLW@SCRC-STONY-BROOK.ARPA adjust-array with :initial-elements and fill pointers
C00648 00198 ∂22-Nov-85 0826 greek%bach.decnet@hudson.dec.com Apology for our brain-damaged mailer.
C00650 00199 ∂22-Nov-85 0856 KMP@SCRC-STONY-BROOK.ARPA adjust-array with :initial-elements and fill pointers
C00655 00200 ∂22-Nov-85 0938 robbins%bach.decnet@hudson.dec.com Recursive printing proposal
C00657 00201 ∂22-Nov-85 1015 RPG Reminder about the Common Lisp Meeting
C00660 00202 ∂22-Nov-85 1106 robbins%bach.decnet@hudson.dec.com LET-IF
C00661 00203 ∂22-Nov-85 1127 FAHLMAN@C.CS.CMU.EDU Recursive printing proposal
C00663 00204 ∂22-Nov-85 1156 greek%bach.decnet@hudson.dec.com TOP-LEVEL-PRINT macro.
C00665 00205 ∂22-Nov-85 1143 FAHLMAN@C.CS.CMU.EDU LET-IF
C00667 00206 ∂22-Nov-85 1208 DLW@SCRC-STONY-BROOK.ARPA adjust-array with :initial-elements and fill pointers
C00671 00207 ∂22-Nov-85 1224 Moon@SCRC-STONY-BROOK.ARPA LET-IF
C00674 00208 ∂22-Nov-85 1243 Moon@SCRC-STONY-BROOK.ARPA :Structure-Print and *print-level*
C00679 00209 ∂22-Nov-85 1249 Moon@SCRC-STONY-BROOK.ARPA Fill-pointers and sequences
C00684 00210 ∂22-Nov-85 1253 Moon@SCRC-STONY-BROOK.ARPA TYPEP and arrays of (SATISFIES F)
C00689 00211 ∂22-Nov-85 1304 greek%bach.decnet@hudson.dec.com Common LISP is too big?
C00691 00212 ∂22-Nov-85 1304 robbins%bach.decnet@hudson.dec.com LET-IF
C00694 00213 ∂22-Nov-85 1305 KMP@SCRC-STONY-BROOK.ARPA Recursive printing proposal
C00698 00214 ∂22-Nov-85 1321 KMP@SCRC-STONY-BROOK.ARPA adjust-array with :initial-elements and fill pointers
C00703 00215 ∂22-Nov-85 1328 FAHLMAN@C.CS.CMU.EDU Fill-pointers and sequences
C00707 00216 ∂22-Nov-85 1331 FAHLMAN@C.CS.CMU.EDU LET-IF
C00709 00217 ∂22-Nov-85 1352 FAHLMAN@C.CS.CMU.EDU Recursive printing proposal
C00711 00218 ∂22-Nov-85 1419 greek%bach.decnet@hudson.dec.com Sigh on recursive printing.
C00713 00219 ∂22-Nov-85 1430 FAHLMAN@C.CS.CMU.EDU LET-IF
C00717 00220 ∂22-Nov-85 1515 JAR@MIT-MC.ARPA LET-IF
C00718 00221 ∂22-Nov-85 1636 DLW@SCRC-STONY-BROOK.ARPA Sigh on recursive printing.
C00720 00222 ∂22-Nov-85 1722 GJC@MIT-MC.ARPA Recursive printing proposal
C00722 00223 ∂22-Nov-85 1733 robbins%bach.decnet@hudson.dec.com LET-IF
C00723 00224 ∂22-Nov-85 1743 Moon@SCRC-QUABBIN.ARPA Sigh on recursive printing.
C00725 00225 ∂22-Nov-85 1743 GJC@MIT-MC.ARPA LET-IF
C00728 00226 ∂23-Nov-85 0913 shebs%utah-orion@utah-cs.arpa Misc Queries
C00731 00227 ∂23-Nov-85 1348 DLW@SCRC-STONY-BROOK.ARPA Minor typo
C00733 00228 ∂23-Nov-85 1356 Moon@SCRC-STONY-BROOK.ARPA Misc Queries
C00739 00229 ∂23-Nov-85 1429 FAHLMAN@C.CS.CMU.EDU Misc Queries
C00741 00230 ∂23-Nov-85 1628 RPG Minor Typo = Major Faux Pas!
C00742 00231 ∂23-Nov-85 1933 mips!escargot.earl@glacier Misc Queries
C00745 00232 ∂24-Nov-85 0930 shebs%utah-orion@utah-cs.arpa Re: Misc Queries
C00750 00233 ∂24-Nov-85 1500 Moon@SCRC-STONY-BROOK.ARPA Re: Misc Queries
C00753 00234 ∂25-Nov-85 0739 gls@THINK-AQUINAS.ARPA LET-IF
C00755 00235 ∂25-Nov-85 0747 gls@THINK-AQUINAS.ARPA Minor typo
C00757 00236 ∂25-Nov-85 0752 gls@THINK-AQUINAS.ARPA Minor Typo = Major Faux Pas!
C00760 00237 ∂25-Nov-85 1408 @SCRC-RIVERSIDE.ARPA:rsl@RUSSIAN.SPA.Symbolics.COM LET-IF
C00763 00238 ∂25-Nov-85 1547 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Typos on p.284 and p.324
C00765 00239 ∂25-Nov-85 1715 RPG New, Improved Agenda
C00769 00240 ∂26-Nov-85 0537 BSG@SCRC-STONY-BROOK.ARPA LET-IF
C00772 00241 ∂26-Nov-85 0805 GJC@MIT-MC.ARPA Mr Roberts vs Mr Rogers
C00773 00242 ∂26-Nov-85 0940 GJC@MIT-MC.ARPA Mr Roberts vs Mr Rogers
C00774 00243 ∂26-Nov-85 0959 gls@THINK-AQUINAS.ARPA LET-IF
C00779 00244 ∂26-Nov-85 1128 hplabs!schumacher@hplabs.ARPA Amatuer Archivists.
C00781 00245 ∂26-Nov-85 1200 gls@THINK-AQUINAS.ARPA Amatuer Archivists.
C00784 00246 ∂26-Nov-85 1202 gls@THINK-AQUINAS.ARPA Amatuer Archivists (again)
C00786 00247 ∂26-Nov-85 1202 KMP@SCRC-STONY-BROOK.ARPA DEFSTRUCT and predicates
C00788 00248 ∂26-Nov-85 1224 WHOLEY@C.CS.CMU.EDU DEFSTRUCT and predicates
C00791 00249 ∂26-Nov-85 1418 NGALL@BBNG.ARPA Re: DEFSTRUCT and predicates
C00795 00250 ∂26-Nov-85 1528 WHOLEY@C.CS.CMU.EDU DEFSTRUCT and predicates
C00798 00251 ∂26-Nov-85 2233 TIM@MIT-MC.ARPA Amatuer Archivists (again)
C00801 00252 ∂27-Nov-85 1901 mips!escargot.earl@glacier lexical scope and dynamic extent
C00803 00253 ∂27-Nov-85 2011 BROOKS%MIT-OZ@MIT-MC.ARPA Re: lexical scope and dynamic extent
C00806 00254 ∂28-Nov-85 1051 ACUFF@SUMEX-AIM.ARPA Re: lexical scope and dynamic extent
C00808 00255 ∂30-Nov-85 1245 RPG ANSI/ISO
C00811 00256 ∂30-Nov-85 1257 RPG More on the CL meeting
C00815 00257 ∂01-Dec-85 1219 DLW@SCRC-STONY-BROOK.ARPA lexical scope and dynamic extent
C00818 00258 ∂01-Dec-85 1645 NGALL@BBNG.ARPA Re: DEFSTRUCT and predicates
C00822 00259 ∂01-Dec-85 1756 Moon@SCRC-STONY-BROOK.ARPA More on the CL meeting
C00825 00260 ∂02-Dec-85 0815 FAHLMAN@C.CS.CMU.EDU ANSI/ISO
C00829 00261 ∂02-Dec-85 0822 FAHLMAN@C.CS.CMU.EDU More on the CL meeting
C00831 00262 ∂02-Dec-85 0828 DLW@SCRC-STONY-BROOK.ARPA More on the CL meeting
C00835 00263 ∂02-Dec-85 1051 FAHLMAN@C.CS.CMU.EDU as I was saying...
C00837 00264 ∂02-Dec-85 1054 RPG ANSI/ISO and Hotel Strike
C00841 00265 ∂02-Dec-85 1135 FAHLMAN@C.CS.CMU.EDU ANSI/ISO and Hotel Strike
C00847 00266 ∂02-Dec-85 1153 RPG Exposing My Machiavellan Tendencies
C00850 00267 ∂02-Dec-85 1209 FAHLMAN@C.CS.CMU.EDU Exposing My Machiavellan Tendencies
C00853 00268 ∂02-Dec-85 1250 DLW@SCRC-QUABBIN.ARPA ANSI/ISO
C00855 00269 ∂02-Dec-85 1622 DLW@SCRC-STONY-BROOK.ARPA ANSI/ISO
C00860 00270 ∂02-Dec-85 1738 Moon@SCRC-STONY-BROOK.ARPA Hotel Strike
C00862 00271 ∂02-Dec-85 2037 FAHLMAN@C.CS.CMU.EDU Charter stuff
C00880 00272 ∂03-Dec-85 1706 hplabs!snyder@hplabsd manual bug (index)
C00881 00273 ∂03-Dec-85 1719 hplabs!snyder@hplabsd keywords
C00883 00274 ∂03-Dec-85 1954 FAHLMAN@C.CS.CMU.EDU keywords
C00885 00275 ∂03-Dec-85 2030 RPG More on Issues
C00888 00276 ∂04-Dec-85 0120 TIM@MIT-MC.ARPA The variables +, -, *, and /
C00890 00277 ∂04-Dec-85 0301 wagner%fang@gswd-vms minor index errors
C00891 00278 ∂04-Dec-85 0310 smh@mit-ems.ARPA Re: The variables +, -, *, and /
C00894 00279 ∂04-Dec-85 0312 BSG@SCRC-STONY-BROOK.ARPA keywords
C00897 00280 ∂04-Dec-85 0806 FAHLMAN@C.CS.CMU.EDU keywords
C00900 00281 ∂04-Dec-85 0814 FAHLMAN@C.CS.CMU.EDU The variables +, -, *, and /
C00902 00282 ∂04-Dec-85 0833 FAHLMAN@C.CS.CMU.EDU More on Issues
C00907 00283 ∂04-Dec-85 0837 @MIT-MC.ARPA:Soley@MIT-MC.ARPA The variables +, -, *, and /
C00910 00284 ∂04-Dec-85 0844 AS@HP-HULK Re: keywords
C00912 00285 ∂04-Dec-85 1006 KMP@SCRC-STONY-BROOK.ARPA The variables +, -, *, and /
C00915 00286 ∂04-Dec-85 1019 BSG@SCRC-STONY-BROOK.ARPA Re: keywords
C00918 00287 ∂04-Dec-85 1109 BSG@SCRC-STONY-BROOK.ARPA Re: keywords
C00921 00288 ∂04-Dec-85 1344 MLY@MIT-MC.ARPA keywords
C00922 00289 ∂05-Dec-85 0023 REM%IMSSS.#Pup@SU-SCORE.ARPA Bad to hang properties off keywords to install their semantics
C00926 00290 ∂05-Dec-85 0118 @SU-SCORE.ARPA:DOUG@SU-CSLI.ARPA Bad to hang properties off keywords to install their semantics
C00928 00291 ∂05-Dec-85 0135 REM@IMSSS Implementation issue? (re proplist on keyword)
C00931 00292 ∂05-Dec-85 0638 @SU-SCORE.ARPA:BSG@SCRC-YUKON.ARPA Bad to hang properties off keywords to install their semantics
C00935 00293 ∂05-Dec-85 0841 AS@HP-HULK Keywords with cells
C00937 00294 ∂05-Dec-85 1049 LOOSEMORE@UTAH-20.ARPA keywords
C00939 00295 ∂05-Dec-85 1101 FAHLMAN@C.CS.CMU.EDU Keywords with cells
C00941 00296 ∂05-Dec-85 1649 DLW@SCRC-STONY-BROOK.ARPA Charter stuff
C00945 00297 ∂05-Dec-85 1728 FAHLMAN@C.CS.CMU.EDU ISO
C00951 00298 ∂06-Dec-85 0028 TIM@MIT-MC.ARPA The variables +, -, *, and /
C00955 00299 ∂06-Dec-85 0606 GJC@MIT-MC.ARPA macsyma and common-lisp
C00959 00300 ∂06-Dec-85 0642 KMP@SCRC-VALLECITO.ARPA The variables +, -, *, and /
C00966 00301 ∂06-Dec-85 0702 FAHLMAN@C.CS.CMU.EDU The variables +, -, *, and /
C00970 00302 ∂06-Dec-85 1223 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK ISO Standard
C00973 00303 ∂06-Dec-85 1321 FAHLMAN@C.CS.CMU.EDU ISO Standard
C00975 00304 ∂06-Dec-85 1916 TIM@MIT-MC.ARPA The variables +, -, *, and /
C00977 00305 ∂07-Dec-85 0719 FAHLMAN@C.CS.CMU.EDU The variables +, -, *, and /
C00981 00306 ∂07-Dec-85 1206 RPG Legal Issues
C00983 00307 ∂07-Dec-85 1723 REM@IMSSS need subset of CL!
C00986 00308 ∂07-Dec-85 2328 masinter.PA@Xerox.ARPA packages
C00988 00309 ∂08-Dec-85 0606 FAHLMAN@C.CS.CMU.EDU packages
C00990 00310 ∂08-Dec-85 1107 DLW@SCRC-STONY-BROOK.ARPA need subset of CL!
C00992 00311 ∂08-Dec-85 1806 RWK@SCRC-STONY-BROOK.ARPA The variables +, -, *, and /
C00996 00312 ∂08-Dec-85 1823 MATHIS@USC-ISIF.ARPA Re: ISO Standard
C00997 00313 ∂10-Dec-85 1352 hplabs!perdue@hplabsd Macrolet index bug
C00998 00314 ∂12-Dec-85 1836 shebs%utah-orion@utah-cs.arpa Special Form Question
C01000 00315 ∂13-Dec-85 0705 DLW@SCRC-STONY-BROOK.ARPA Special Form Question
C01003 00316 ∂13-Dec-85 0708 NGALL@BBNG.ARPA Re: Special Form Question
C01007 00317 ∂13-Dec-85 0744 shebs%utah-orion@utah-cs.arpa Re: Special Form Question
C01010 00318 ∂13-Dec-85 0804 FAHLMAN@C.CS.CMU.EDU Special Form Question
C01013 00319 ∂13-Dec-85 1022 Moon@SCRC-QUABBIN.ARPA Special Form Question
C01017 00320 ∂13-Dec-85 1101 NGALL@BBNG.ARPA Re: Special Form Question
C01021 00321 ∂13-Dec-85 1109 NGALL@BBNG.ARPA Re: Special Form Question
C01024 00322 ∂13-Dec-85 1155 shebs%utah-orion@utah-cs.arpa Clarification Comments (long)
C01034 00323 ∂13-Dec-85 1215 gls@THINK-AQUINAS.ARPA list of proposed changes to Common Lisp
C01059 00324 ∂13-Dec-85 1217 gls@THINK-AQUINAS.ARPA Typographical corrections to Common Lisp book
C01077 00325 ∂13-Dec-85 1320 gls@THINK-AQUINAS.ARPA Clarification Comments (long)
C01084 00326 ∂13-Dec-85 1401 shebs%utah-orion@utah-cs.arpa Re: Clarification Comments (long)
C01091 00327 ∂13-Dec-85 1606 REM%IMSSS.#Pup@SU-SCORE.ARPA What about advising special forms?
C01093 00328 ∂13-Dec-85 1703 Moon@SCRC-STONY-BROOK.ARPA Re: Special Form Question
C01095 00329 ∂13-Dec-85 1846 FAHLMAN@C.CS.CMU.EDU What about advising special forms?
C01098 00330 ∂13-Dec-85 1903 FAHLMAN@C.CS.CMU.EDU Re: Special Form Question
C01102 00331 ∂13-Dec-85 2146 RAM@C.CS.CMU.EDU list of proposed changes to Common Lisp
C01111 00332 ∂14-Dec-85 1752 edsel!eb@su-navajo.arpa Undoing global side-effects
C01116 00333 ∂14-Dec-85 1953 edsel!eb@su-navajo.arpa Questions, comments and clarifications on clarifications
C01122 00334 ∂14-Dec-85 1953 edsel!eb@su-navajo.arpa More clarifications
C01125 00335 ∂15-Dec-85 1155 RAM@C.CS.CMU.EDU Another omission: global lexicals
C01128 00336 ∂15-Dec-85 1322 RPG [Richard Acuff <Acuff@SUMEX-AIM.ARPA>: Summary of Common Lisp meeting]
C01138 00337 ∂15-Dec-85 1327 DLW@SCRC-STONY-BROOK.ARPA Questions, comments and clarifications on clarifications
C01146 00338 ∂15-Dec-85 1330 DLW@SCRC-STONY-BROOK.ARPA Another omission: global lexicals
C01148 00339 ∂15-Dec-85 1341 Moon@SCRC-STONY-BROOK.ARPA XOR
C01150 00340 ∂15-Dec-85 1350 RAM@C.CS.CMU.EDU Another omission: global lexicals
C01153 00341 ∂15-Dec-85 1447 DLW@SCRC-STONY-BROOK.ARPA Another omission: global lexicals
C01158 00342 ∂15-Dec-85 1447 RAM@C.CS.CMU.EDU Another Common Lisp unclarity
C01162 00343 ∂15-Dec-85 1455 REM%IMSSS.#Pup@SU-SCORE.ARPA Elegant rule for what to copy
C01165 00344 ∂15-Dec-85 1503 GJC@MIT-MC.ARPA Another omission: global lexicals
C01168 00345 ∂15-Dec-85 1541 RAM@C.CS.CMU.EDU Another omission: global lexicals
C01170 00346 ∂15-Dec-85 1608 RPG Name change
C01173 00347 ∂15-Dec-85 1621 RAM@C.CS.CMU.EDU Minor package unclarity
C01175 00348 ∂15-Dec-85 1631 RPG
C01176 00349 ∂15-Dec-85 1631 RPG Please add `mly-lispm@mit-mc' to cl-error-handling
C01177 00350 ∂15-Dec-85 1659 RAM@C.CS.CMU.EDU unclarities: defstruct print functions
C01179 00351 ∂15-Dec-85 1855 JAR@MIT-MC.ARPA Another omission: global lexicals
C01188 00352 ∂15-Dec-85 1935 RAM@C.CS.CMU.EDU list of proposed changes to Common Lisp
C01193 00353 ∂15-Dec-85 2128 RAM@C.CS.CMU.EDU Another omission: global lexicals
C01196 00354 ∂15-Dec-85 2134 RAM@C.CS.CMU.EDU Another omission: global lexicals
C01199 00355 ∂16-Dec-85 0303 cfry%MIT-OZ@MIT-MC.ARPA clarifications
C01201 00356 ∂16-Dec-85 0641 DLW@SCRC-STONY-BROOK.ARPA Another omission: global lexicals
C01203 00357 ∂16-Dec-85 0657 wagner%fang@gswd-vms &ALLOW-OTHER-KEYS
C01205 00358 ∂16-Dec-85 0704 DLW@SCRC-STONY-BROOK.ARPA Another omission: global lexicals
C01207 00359 ∂16-Dec-85 0935 gls@THINK-AQUINAS.ARPA list of proposed changes to Common Lisp
C01210 00360 ∂16-Dec-85 1002 gls@THINK-AQUINAS.ARPA Questions, comments and clarifications on clarifications
C01213 00361 ∂16-Dec-85 1005 gls@THINK-AQUINAS.ARPA XOR
C01215 00362 ∂16-Dec-85 1014 gls@THINK-AQUINAS.ARPA Another omission: global lexicals
C01219 00363 ∂16-Dec-85 1032 gls@THINK-AQUINAS.ARPA meta corrections to CLtL
C01221 00364 ∂16-Dec-85 1035 gls@THINK-AQUINAS.ARPA &ALLOW-OTHER-KEYS
C01223 00365 ∂16-Dec-85 1058 DCP@SCRC-QUABBIN.ARPA get-setf-method
C01225 00366 ∂16-Dec-85 1058 DLW@SCRC-QUABBIN.ARPA Questions, comments and clarifications on clarifications
C01228 00367 ∂16-Dec-85 1149 DLW@SCRC-QUABBIN.ARPA Another omission: global lexicals
C01232 00368 ∂16-Dec-85 1154 RAM@C.CS.CMU.EDU list of proposed changes to Common Lisp
C01235 00369 ∂16-Dec-85 1400 masinter.pa@Xerox.ARPA Re: Special Form Question
C01237 00370 ∂16-Dec-85 1412 GSB@MIT-MC.ARPA get-setf-method
C01239 00371 ∂16-Dec-85 1518 masinter.pa@Xerox.ARPA Re: clarifications
C01241 00372 ∂16-Dec-85 1524 DCP@SCRC-STONY-BROOK.ARPA XOR
C01244 00373 ∂16-Dec-85 1703 mips!escargot.earl@glacier Re: Special Form Question
C01248 00374 ∂16-Dec-85 2018 DLW@SCRC-STONY-BROOK.ARPA Non-top-level DEFUN
C01250 00375 ∂16-Dec-85 2042 FAHLMAN@C.CS.CMU.EDU Non-top-level DEFUN
C01252 00376 ∂17-Dec-85 0808 gls@THINK-AQUINAS.ARPA Questions, comments and clarifications on clarifications
C01255 00377 ∂17-Dec-85 0911 gls@THINK-AQUINAS.ARPA Questions, comments and clarifications on clarifications
C01258 00378 ∂17-Dec-85 1026 vanroggen%bizet.decnet@hudson.dec.com more comments
C01265 00379 ∂17-Dec-85 1129 edsel!jonl@su-navajo.arpa Functions for special operators
C01272 00380 ∂17-Dec-85 1129 edsel!jonl@su-navajo.arpa "lexical" globals?
C01287 00381 ∂17-Dec-85 1633 KMP@SCRC-STONY-BROOK.ARPA XOR
C01293 00382 ∂17-Dec-85 2126 KMP@SCRC-STONY-BROOK.ARPA XOR
C01299 00383 ∂17-Dec-85 2157 JAR@MIT-MC.ARPA "lexical" globals?
C01303 00384 ∂17-Dec-85 2213 mcvax!delphi.UUCP!beppe@seismo.CSS.GOV mailing list
C01305 00385 ∂18-Dec-85 0330 cfry%MIT-OZ@MIT-MC.ARPA Re: clarifications
C01311 00386 ∂18-Dec-85 0701 preece%ccvaxa@gswd-vms Re: XOR
C01314 00387 ∂18-Dec-85 0842 @MC.LCS.MIT.EDU:RAMBO@AI.AI.MIT.EDU recent request for assistance
C01316 00388 ∂18-Dec-85 1153 Gregor.pa@Xerox.ARPA what do :copiers do?
C01318 00389 ∂19-Dec-85 0932 gls@THINK-AQUINAS.ARPA XOR
C01321 00390 ∂19-Dec-85 0935 gls@THINK-AQUINAS.ARPA READ-DELIMTED-LIST and dots
C01323 00391 ∂19-Dec-85 1346 Masinter.pa@Xerox.ARPA fonts in CLtL
C01328 00392 ∂19-Dec-85 2051 apollo!dfm@uw-beaver.arpa GLS's clarifications list (moderately long)
C01343 00393 ∂20-Dec-85 1203 FAHLMAN@C.CS.CMU.EDU fonts in CLtL
C01347 00394 ∂20-Dec-85 1211 gls@THINK-AQUINAS.ARPA GLS's clarifications list (moderately long)
C01353 00395 ∂20-Dec-85 1403 gls@THINK-AQUINAS.ARPA Multiple values and &optional
C01356 00396 ∂20-Dec-85 1636 DLW@SCRC-STONY-BROOK.ARPA GLS's clarifications list (moderately long)
C01358 00397 ∂20-Dec-85 2356 apollo!dfm@uw-beaver.arpa Re: Elegant rule for what to copy
C01360 00398 ∂21-Dec-85 1724 Moon@SCRC-STONY-BROOK.ARPA Multiple values and &optional
C01361 00399 ∂21-Dec-85 1738 NGALL@BBNG.ARPA Re: Multiple values and &optional
C01364 00400 ∂21-Dec-85 2102 NGALL@BBNG.ARPA Re: Multiple values and &optional
C01367 00401 ∂23-Dec-85 0030 MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA Comments
C01374 00402 ∂23-Dec-85 0756 NGALL@BBNG.ARPA Re: Comments
C01382 00403 ∂23-Dec-85 0756 GSB@MC.LCS.MIT.EDU xor
C01384 00404 ∂23-Dec-85 0756 FAHLMAN@C.CS.CMU.EDU Comments
C01388 00405 ∂23-Dec-85 1029 REM%IMSSS.#Pup@SU-SCORE.ARPA Ground rules not yet decided???
C01390 00406 ∂23-Dec-85 1323 JAR@MC.LCS.MIT.EDU unspecial & global & macrolet
C01393 00407 ∂23-Dec-85 1357 FAHLMAN@C.CS.CMU.EDU Ground rules not yet decided???
C01402 00408 ∂23-Dec-85 2058 apollo!dfm@uw-beaver.arpa copy (moderately long message)
C01416 00409 ∂23-Dec-85 2058 α@uw-beaver.arpa
C01417 00410 ∂24-Dec-85 1530 gls@THINK-AQUINAS.ARPA Reader hacks
C01419 00411 ∂24-Dec-85 1535 gls@THINK-AQUINAS.ARPA GLS's clarifications list (moderately long)
C01421 00412 ∂26-Dec-85 0934 Moon@SCRC-STONY-BROOK.ARPA Symbols as pathnames
C01428 00413 ∂26-Dec-85 1012 Moon@SCRC-STONY-BROOK.ARPA XOR
C01431 00414 ∂26-Dec-85 1028 gls@THINK-AQUINAS.ARPA Comments
C01435 00415 ∂26-Dec-85 1054 Moon@SCRC-STONY-BROOK.ARPA Reader hacks
C01438 00416 ∂26-Dec-85 1139 Bobrow.pa@Xerox.ARPA Re: copy
C01440 00417 ∂26-Dec-85 1240 LOOSEMORE@UTAH-20.ARPA BOA constructor questions
C01442 00418 ∂26-Dec-85 1309 gls@THINK-AQUINAS.ARPA BOA constructor questions
C01446 00419 ∂26-Dec-85 1342 GSB@MC.LCS.MIT.EDU Reader hacks
C01450 00420 ∂26-Dec-85 1628 REM%IMSSS.#Pup@SU-SCORE.ARPA COPY and COPY-IN
C01452 00421 ∂26-Dec-85 1706 @SU-SCORE.ARPA:Bobrow.pa@Xerox.ARPA Re: COPY and COPY-IN
C01455 00422 ∂26-Dec-85 1959 Moon@SCRC-STONY-BROOK.ARPA XOR
C01459 00423 ∂26-Dec-85 2000 Moon@SCRC-STONY-BROOK.ARPA RE: Symbols as pathnames
C01462 00424 ∂27-Dec-85 0320 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU GLS's clarifications list (moderately long)
C01464 00425 ∂27-Dec-85 0530 GJC@MC.LCS.MIT.EDU Reader hacks
C01466 00426 ∂27-Dec-85 1054 LOOSEMORE@UTAH-20.ARPA Another inconsistency in CLtL
C01468 00427 ∂28-Dec-85 1509 Moon@SCRC-YUKON.ARPA BOA constructor questions
C01473 00428 ∂28-Dec-85 1533 edsel!eb@su-navajo.arpa Tail recursive Common Lisp interpreter?
C01477 00429 ∂28-Dec-85 1636 GJC@MC.LCS.MIT.EDU Tail recursive Common Lisp interpreter?
C01480 00430 ∂29-Dec-85 1415 DCP@SCRC-STONY-BROOK.ARPA Multiple values and &optional
C01482 00431 ∂29-Dec-85 1524 NGALL@BBNG.ARPA Re: Reader hacks
C01485 00432 ∂30-Dec-85 0237 REM@IMSSS Retry, IMSSS->SCORE mail down a few days Flush implicit catch frames
C01489 00433 ∂30-Dec-85 0601 GJC@MC.LCS.MIT.EDU tail recursion in CL interpreters.
C01491 00434 ∂30-Dec-85 0832 gls@THINK-AQUINAS.ARPA BOA constructor questions
C01496 00435 ∂30-Dec-85 1231 JAR@MC.LCS.MIT.EDU Retry, IMSSS->SCORE mail down a few days Flush implicit catch frames
C01500 00436 ∂30-Dec-85 1247 REM%IMSSS.#Pup@SU-SCORE.ARPA Reader hacks, whitespace algorithm
C01502 00437 ∂02-Jan-86 1022 GSB@MC.LCS.MIT.EDU Re: Reader hacks
C01504 00438 ∂03-Jan-86 0050 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Re: Reader hacks
C01507 00439 ∂03-Jan-86 0818 REM%IMSSS.#Pup@SU-SCORE.ARPA Reader hacks, whitespace algorithm
C01509 00440 ∂03-Jan-86 0917 LOOSEMORE@UTAH-20.ARPA yet another typo in the manual
C01510 00441 ∂04-Jan-86 1905 @SU-SCORE.ARPA:GSB@MC.LCS.MIT.EDU Reader hacks, whitespace algorithm
C01512 00442 ∂05-Jan-86 1523 shebs%utah-orion@utah-cs.arpa Defsetf and define-setf-method
C01514 00443 ∂06-Jan-86 0854 RAM@C.CS.CMU.EDU Another inconsistency in CLtL
C01516 00444 ∂06-Jan-86 1323 Moon@SCRC-YUKON.ARPA Defsetf and define-setf-method
C01520 00445 ∂07-Jan-86 0038 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Type questions
C01522 00446 ∂07-Jan-86 0911 gls@THINK-AQUINAS.ARPA Type questions
C01526 00447 ∂07-Jan-86 0913 gls@THINK-AQUINAS.ARPA No more index typos, please
C01528 00448 ∂08-Jan-86 0839 kempf@hplabsc Hooks for Common Objects
C01535 00449 ∂09-Jan-86 0847 gls@THINK-AQUINAS.ARPA Common Lisp 'open'
C01538 00450 ∂09-Jan-86 1910 LOOSEMORE@UTAH-20.ARPA questions about packages
C01540 00451 ∂10-Jan-86 0711 NGALL@G.BBN.COM Re: questions about packages
C01543 00452 ∂10-Jan-86 0941 RPG Varia from Tektronix
C01545 00453 ∂10-Jan-86 1102 GJC@MC.LCS.MIT.EDU SETF of an &REST list.
C01547 00454 ∂12-Jan-86 0642 RAM@C.CS.CMU.EDU fill-pointers and destructive sequence functions
C01550 00455 ∂13-Jan-86 1711 LOOSEMORE@UTAH-20.ARPA time of evaluation
C01552 00456 ∂14-Jan-86 1217 @MC.LCS.MIT.EDU:Soley@MC.LCS.MIT.EDU time of evaluation
C01555 00457 ∂14-Jan-86 1854 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Errata on p.431
C01557 00458 ∂15-Jan-86 0606 BSG@SCRC-STONY-BROOK.ARPA time of evaluation
C01561 00459 ∂15-Jan-86 0815 SOLEY@MC.LCS.MIT.EDU time of evaluation
C01564 00460 ∂15-Jan-86 0858 DLW@SCRC-STONY-BROOK.ARPA time of evaluation
C01570 00461 ∂15-Jan-86 1002 kempf@hplabsc Re: time of evaluation
C01574 00462 ∂15-Jan-86 1049 FAHLMAN@C.CS.CMU.EDU time of evaluation
C01579 00463 ∂15-Jan-86 1226 RAM@C.CS.CMU.EDU time of evaluation
C01583 00464 ∂15-Jan-86 1430 LOOSEMORE@UTAH-20.ARPA Re: time of evaluation
C01587 00465 ∂15-Jan-86 1445 DLW@SCRC-STONY-BROOK.ARPA time of evaluation
C01590 00466 ∂15-Jan-86 1457 RAM@C.CS.CMU.EDU time of evaluation
C01592 00467 ∂15-Jan-86 1504 Moon@SCRC-STONY-BROOK.ARPA time of evaluation of defstruct, deftype, etc.
C01596 00468 ∂15-Jan-86 1728 FAHLMAN@C.CS.CMU.EDU time of evaluation
C01602 00469 ∂15-Jan-86 1736 FAHLMAN@C.CS.CMU.EDU time of evaluation of defstruct, deftype, etc.
C01605 00470 ∂15-Jan-86 1850 Moon@SCRC-STONY-BROOK.ARPA time of evaluation of defstruct, deftype, etc.
C01608 00471 ∂16-Jan-86 0141 REM@IMSSS 2 ways to compile macros correctly
C01614 00472 ∂16-Jan-86 1126 HEDRICK@RED.RUTGERS.EDU compiler enviornment
C01618 00473 ∂16-Jan-86 1407 REM@IMSSS compiler environment, how best to isolate side effects
C01628 00474 ∂17-Jan-86 0303 GJC@MC.LCS.MIT.EDU compiler enviornment
C01630 00475 ∂17-Jan-86 0701 pyramid!bein@sri-unix compile environment..
C01637 00476 ∂17-Jan-86 0753 FAHLMAN@C.CS.CMU.EDU compile environment..
C01640 00477 ∂17-Jan-86 1628 DLW@SCRC-QUABBIN.ARPA time of evaluation
C01645 00478 ∂17-Jan-86 1644 DLW@SCRC-QUABBIN.ARPA compiler environment, how best to isolate side effects
C01649 00479 ∂17-Jan-86 1813 hplabs!snyder@hplabs.ARPA Re: time of evaluation
C01653 00480 ∂19-Jan-86 1537 pyramid!bein@sri-unix floating point question
C01656 00481 ∂19-Jan-86 1559 RPG
C01659 00482 ∂19-Jan-86 1706 FAHLMAN@C.CS.CMU.EDU floating point question
C01662 00483 ∂19-Jan-86 1736 Moon@SCRC-STONY-BROOK.ARPA floating point question
C01664 00484 ∂20-Jan-86 0951 BACH@SU-SCORE.ARPA Spelling correction
C01666 00485 ∂20-Jan-86 1023 FAHLMAN@C.CS.CMU.EDU Spelling correction
C01670 00486 ∂20-Jan-86 1052 DCP@SCRC-QUABBIN.ARPA Spelling correction
C01674 00487 ∂20-Jan-86 1859 RPG the Common-Lisp mailinglist
C01676 00488 ∂21-Jan-86 0836 gls@THINK-AQUINAS.ARPA Spelling correction
C01681 00489 ∂21-Jan-86 1039 SCHUMACHER@HP-HULK
C01682 00490 ∂22-Jan-86 1324 DDYER@SCRC-QUABBIN.ARPA Spelling correction
C01690 00491 ∂22-Jan-86 1738 BACH@SU-SCORE.ARPA Re: Spelling correction
C01692 00492 ∂22-Jan-86 2048 shebs%utah-orion@utah-cs.arpa Re: Spelling correction
C01694 00493 ∂22-Jan-86 2228 shebs%utah-orion@utah-cs.arpa Re: Spelling correction
C01696 00494 ∂23-Jan-86 0657 FAHLMAN@C.CS.CMU.EDU Spelling correction
C01699 00495 ∂23-Jan-86 1333 gls@THINK-AQUINAS.ARPA [vrotney@isi-vaxa.ARPA: Forwarded]
C01701 00496 ∂23-Jan-86 1847 mips!escargot.earl@glacier time of evaluation
C01704 00497 ∂23-Jan-86 2124 Moon@SCRC-STONY-BROOK.ARPA [vrotney@isi-vaxa.ARPA: Forwarded]
C01706 00498 ∂23-Jan-86 2253 GSB@MC.LCS.MIT.EDU common-lisp loop
C01708 00499 ∂24-Jan-86 1258 fateman@dali.berkeley.edu comparisons between floats and ratios
C01711 00500 ∂24-Jan-86 1618 Cassels@SCRC-STONY-BROOK.ARPA comparisons between floats and ratios
C01718 00501 ∂24-Jan-86 1935 Cassels@SCRC-STONY-BROOK.ARPA comparisons between floats and ratios
C01725 00502 ∂24-Jan-86 1946 FAHLMAN@C.CS.CMU.EDU comparisons between floats and ratios
C01728 00503 ∂24-Jan-86 2101 fateman@dali.berkeley.edu Re: comparisons between floats and ratios
C01731 00504 ∂26-Jan-86 1324 Moon@SCRC-STONY-BROOK.ARPA Re: comparisons between floats and ratios
C01734 00505 ∂26-Jan-86 1413 fateman@dali.berkeley.edu more boring-to-most-people floating point stuff
C01737 00506 ∂26-Jan-86 1920 GJC@MC.LCS.MIT.EDU precision vs more information
C01739 00507 ∂26-Jan-86 1939 KSH@MC.LCS.MIT.EDU
C01743 00508 ∂27-Jan-86 0543 GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU comparisons between floats and ratios
C01745 00509 ∂27-Jan-86 0644 RAM@C.CS.CMU.EDU Compiler side effects lossage
C01748 00510 ∂27-Jan-86 0737 FAHLMAN@C.CS.CMU.EDU comparisons between floats and ratios
C01750 00511 ∂27-Jan-86 0742 FAHLMAN@C.CS.CMU.EDU comparisons between floats and ratios
C01752 00512 ∂27-Jan-86 0812 DCP@SCRC-VALLECITO.ARPA comparisons between floats and ratios
C01756 00513 ∂27-Jan-86 1153 fateman@dali.berkeley.edu precision, accuracy, and floating conversion (GJC's comment)
C01758 00514 ∂27-Jan-86 1417 gls@THINK-AQUINAS.ARPA precision, accuracy, and floating conversion (GJC's comment)
C01760 00515 ∂27-Jan-86 1449 gls@THINK-AQUINAS.ARPA Comparing float to rational
C01765 00516 ∂27-Jan-86 1608 GJC@MC.LCS.MIT.EDU precision, accuracy, and floating conversion (GJC's comment)
C01767 00517 ∂27-Jan-86 1854 ME :capitalize in *print-case*
C01769 00518 ∂27-Jan-86 2050 FAHLMAN@C.CS.CMU.EDU :capitalize in *print-case*
C01771 00519 ∂27-Jan-86 2110 Moon@SCRC-STONY-BROOK.ARPA :capitalize in *print-case*
C01773 00520 ∂27-Jan-86 2308 fateman@dali.berkeley.edu IEEE float co-processors
C01777 00521 ∂28-Jan-86 0331 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Spelling correction
C01779 00522 ∂28-Jan-86 0452 GJC@MC.LCS.MIT.EDU Spelling correction
C01781 00523 ∂28-Jan-86 0545 FAHLMAN@C.CS.CMU.EDU Spelling correction
C01783 00524 ∂28-Jan-86 0555 FAHLMAN@C.CS.CMU.EDU IEEE float co-processors
C01786 00525 ∂28-Jan-86 0728 csi!meehan%UUCP@YALE.ARPA DEFUN inside LET
C01788 00526 ∂28-Jan-86 0748 DCP@SCRC-STONY-BROOK.ARPA IEEE float co-processors
C01790 00527 ∂28-Jan-86 1108 Moon@SCRC-STONY-BROOK.ARPA IEEE float co-processors
C01792 00528 ∂28-Jan-86 1250 Cassels@SCRC-STONY-BROOK.ARPA Comparing float to rational
C01798 00529 ∂28-Jan-86 1256 Cassels@SCRC-STONY-BROOK.ARPA comparisons between floats and ratios
C01803 00530 ∂28-Jan-86 1309 Cassels@SCRC-STONY-BROOK.ARPA comparisons between floats and ratios
C01806 00531 ∂28-Jan-86 1314 lab@rochester.arpa IEEE float co-processors
C01808 00532 ∂28-Jan-86 1500 REM@IMSSS Rebuttal to incorrect statement of portability definition
C01812 00533 ∂28-Jan-86 1526 Moon@SCRC-STONY-BROOK.ARPA IEEE float co-processors
C01816 00534 ∂28-Jan-86 1803 Cassels@SCRC-STONY-BROOK.ARPA more boring-to-most-people floating point stuff
C01822 00535 ∂28-Jan-86 1823 hilfingr@renoir.berkeley.edu Re: IEEE float co-processors
C01830 00536 ∂28-Jan-86 2015 FAHLMAN@C.CS.CMU.EDU DEFUN inside LET
C01832 00537 ∂29-Jan-86 1040 mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV Floating Point Computation
C01835 00538 ∂29-Jan-86 1052 FAHLMAN@C.CS.CMU.EDU Floating Point Computation
C01837 00539 ∂29-Jan-86 1133 fateman@dali.berkeley.edu Re: Floating Point Computation
C01839 00540 ∂29-Jan-86 1144 JAR@MC.LCS.MIT.EDU DEFUN inside LET
C01841 00541 ∂29-Jan-86 1206 FAHLMAN@C.CS.CMU.EDU DEFUN inside LET
C01843 00542 ∂30-Jan-86 0702 NGALL@G.BBN.COM Re: DEFUN inside LET
C01847 00543 ∂30-Jan-86 0834 mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV Re: Floating Point Computation
C01851 00544 ∂30-Jan-86 1011 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: DEFUN inside LET
C01854 00545 ∂30-Jan-86 1130 FAHLMAN@C.CS.CMU.EDU Defun inside Let
C01856 00546 ∂30-Jan-86 1146 RAM@C.CS.CMU.EDU DEFUN inside of LET
C01860 00547 ∂30-Jan-86 1304 DCP@SCRC-STONY-BROOK.ARPA Defun inside Let
C01865 00548 ∂30-Jan-86 1405 JAR@MC.LCS.MIT.EDU Defun inside Let
C01869 00549 ∂30-Jan-86 1426 smh@mit-ems.ARPA Re: DEFUN inside LET
C01872 00550 ∂30-Jan-86 1506 DCP@SCRC-STONY-BROOK.ARPA Defun inside Let
C01875 00551 ∂30-Jan-86 1529 REM@IMSSS Defun inside Let
C01885 00552 ∂30-Jan-86 1712 smh@mit-ems.ARPA Re: Defun inside Let
C01889 00553 ∂30-Jan-86 1714 RAM@C.CS.CMU.EDU Defun inside Let
C01895 00554 ∂30-Jan-86 1723 mips!escargot.earl@glacier DEFUN inside of LET
C01897 00555 ∂30-Jan-86 1805 @SCRC-QUABBIN.ARPA,@EUPHRATES.SCRC.Symbolics.COM:Moon@SCRC-STONY-BROOK.ARPA Defun inside Let
C01902 00556 ∂30-Jan-86 1805 DCP@SCRC-STONY-BROOK.ARPA Defun inside Let
C01906 00557 ∂30-Jan-86 1811 GJC@MC.LCS.MIT.EDU editing environments
C01909 00558 ∂30-Jan-86 1930 FAHLMAN@C.CS.CMU.EDU Defun inside Let
C01913 00559 ∂30-Jan-86 2050 meehan@YALE.ARPA
C01915 00560 ∂30-Jan-86 2055 FAHLMAN@C.CS.CMU.EDU
C01917 00561 ∂31-Jan-86 0906 DLW@SCRC-STONY-BROOK.ARPA Defun inside Let
C01919 00562 ∂31-Jan-86 0938 DLW@SCRC-QUABBIN.ARPA Defun inside Let
C01922 00563 ∂31-Jan-86 1806 OLDMAN@USC-ISI.ARPA Defmacro inside of a let
C01924 00564 ∂31-Jan-86 1806 OLDMAN@USC-ISI.ARPA &environment
C01925 00565 ∂31-Jan-86 1808 OLDMAN@USC-ISI.ARPA deftype with &key
C01926 00566 ∂31-Jan-86 2156 OLDMAN@USC-ISI.ARPA Defmacro inside of a let
C01928 00567 ∂31-Jan-86 2228 FAHLMAN@C.CS.CMU.EDU &environment
C01930 00568 ∂31-Jan-86 2306 OLDMAN@USC-ISI.ARPA &environment
C01931 00569 ∂31-Jan-86 2337 OLDMAN@USC-ISI.ARPA get-setf-method-multiple-value
C01932 00570 ∂01-Feb-86 0025 OLDMAN@USC-ISI.ARPA deftype with &key
C01933 00571 ∂01-Feb-86 0051 Moon@SCRC-STONY-BROOK.ARPA Retraction
C01936 00572 ∂01-Feb-86 0713 RAM@C.CS.CMU.EDU Defmacro inside of a let
C01938 00573 ∂01-Feb-86 0805 FAHLMAN@C.CS.CMU.EDU Retraction
C01941 00574 ∂01-Feb-86 1235 Moon@SCRC-QUABBIN.ARPA get-setf-method-multiple-value
C01943 00575 ∂01-Feb-86 1500 Moon@SCRC-STONY-BROOK.ARPA deftype with &key
C01945 00576 ∂01-Feb-86 1630 GJC@MC.LCS.MIT.EDU Retraction
C01947 00577 ∂01-Feb-86 1638 smh@mit-ems.ARPA Re: Defun inside Let
C01949 00578 ∂02-Feb-86 1912 DCP@SCRC-STONY-BROOK.ARPA Nothing to do with Common Lisp
C01959 00579 ∂03-Feb-86 0639 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Re: Defun inside Let
C01963 00580 ∂03-Feb-86 0736 FAHLMAN@C.CS.CMU.EDU Defun inside Let
C01966 00581 ∂03-Feb-86 0952 gls@THINK-AQUINAS.ARPA Defun inside Let
C01969 00582 ∂03-Feb-86 1059 REM%IMSSS.#Pup@SU-SCORE.ARPA Jeff Dalton's point
C01971 00583 ∂03-Feb-86 1101 Moon@SCRC-STONY-BROOK.ARPA Re: Re: Defun inside Let
C01974 00584 ∂03-Feb-86 1646 vollum@SCRC-STONY-BROOK.ARPA Re: Defmacro inside of a let
C01978 00585 ∂03-Feb-86 1708 WEEKS@HP-THOR eval'd macros
C01980 00586 ∂03-Feb-86 1738 FAHLMAN@C.CS.CMU.EDU eval'd macros
C01982 00587 ∂03-Feb-86 1905 RAM@C.CS.CMU.EDU Defmacro inside of a let
C01985 00588 ∂04-Feb-86 0734 DCP@SCRC-STONY-BROOK.ARPA eval'd macros
C01988 00589 ∂04-Feb-86 0739 gallagher%umass-cs.csnet@CSNET-RELAY.ARPA Defstruct Extensions
C01993 00590 ∂04-Feb-86 0916 liz@brillig.umd.edu loop macro
C01997 00591 ∂04-Feb-86 0952 kempf@hplabsc Re: Defstruct Extensions
C02000 00592 ∂04-Feb-86 1005 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: eval'd macros
C02002 00593 ∂04-Feb-86 1029 KMP@SCRC-STONY-BROOK.ARPA eval'd macros (the other point of view)
C02007 00594 ∂04-Feb-86 1032 Gregor.pa@Xerox.COM Re: Defstruct Extensions
C02010 00595 ∂04-Feb-86 1037 FAHLMAN@C.CS.CMU.EDU eval'd macros (the other point of view)
C02012 00596 ∂04-Feb-86 1103 FAHLMAN@C.CS.CMU.EDU loop macro
C02014 00597 ∂04-Feb-86 1119 FAHLMAN@C.CS.CMU.EDU loop macro
C02016 00598 ∂04-Feb-86 1319 liz@brillig.umd.edu Re: loop macro
C02019 00599 ∂04-Feb-86 1332 BSG@SCRC-STONY-BROOK.ARPA Re: loop macro
C02023 00600 ∂04-Feb-86 1416 FAHLMAN@C.CS.CMU.EDU loop macro
C02029 00601 ∂04-Feb-86 1434 sean@cadre.dsl.pittsburgh.edu Re: loop macro
C02031 00602 ∂04-Feb-86 1552 Gregor.pa@Xerox.COM Re: loop macro
C02034 00603 ∂04-Feb-86 1556 DLW@SCRC-STONY-BROOK.ARPA loop macro
C02039 00604 ∂04-Feb-86 1651 snyder@hplsny Re: loop macro
C02042 00605 ∂04-Feb-86 1722 FAHLMAN@C.CS.CMU.EDU loop macro
C02044 00606 ∂04-Feb-86 1753 liz@brillig.umd.edu Re: loop macro
C02050 00607 ∂04-Feb-86 1811 FAHLMAN@C.CS.CMU.EDU loop macro
C02055 00608 ∂04-Feb-86 1826 FAHLMAN@C.CS.CMU.EDU loop macro
C02057 00609 ∂04-Feb-86 1954 sean@cadre.dsl.pittsburgh.edu Re: loop macro
C02059 00610 ∂05-Feb-86 0616 FAHLMAN@C.CS.CMU.EDU loop macro
C02061 00611 ∂05-Feb-86 0721 gls@THINK-AQUINAS.ARPA Re: loop macro
C02064 00612 ∂05-Feb-86 0908 gls@THINK-AQUINAS.ARPA Re: loop macro
C02078 00613 ∂05-Feb-86 1501 shebs%utah-orion@utah-cs.arpa GLS replacements for LOOP
C02081 00614 ∂05-Feb-86 1522 @MC.LCS.MIT.EDU:Soley@MC.LCS.MIT.EDU Re: loop macro
C02084 00615 ∂05-Feb-86 1522 AI.BOYER@MCC.ARPA loop speed
C02086 00616 ∂05-Feb-86 1529 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: eval'd macros (the other point of view)
C02089 00617 ∂05-Feb-86 1536 Fitch%cs.ucl.ac.uk@Cs.Ucl.AC.UK LISP standardisation
C02096 00618 ∂05-Feb-86 1650 hpfclp!diamant@hplabs.ARPA Re: eval'd macros (the other point of view)
C02101 00619 ∂05-Feb-86 1650 willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA lexical scope & program development
C02107 00620 ∂05-Feb-86 1738 hpfclp!diamant@hplabs.ARPA intern
C02112 00621 ∂05-Feb-86 1900 BSG@SCRC-STONY-BROOK.ARPA Re: loop macro
C02115 00622 ∂05-Feb-86 1901 DLW@SCRC-STONY-BROOK.ARPA loop macro
C02126 00623 ∂05-Feb-86 2025 FAHLMAN@C.CS.CMU.EDU eval'd macros (the other point of view)
C02132 00624 ∂05-Feb-86 2051 FAHLMAN@C.CS.CMU.EDU loop macro
C02135 00625 ∂05-Feb-86 2123 FAHLMAN@C.CS.CMU.EDU eval'd macros (the other point of view)
C02140 00626 ∂05-Feb-86 2310 zorn@renoir.berkeley.edu Interest in "large" Common Lisp Programs
C02143 00627 ∂06-Feb-86 0507 DLW@SCRC-STONY-BROOK.ARPA lexical scope & program development
C02145 00628 ∂06-Feb-86 0514 DLW@SCRC-STONY-BROOK.ARPA Re: loop macro
C02149 00629 ∂06-Feb-86 0659 NGALL@G.BBN.COM Re: intern
C02152 00630 ∂06-Feb-86 0704 sean@cadre.dsl.pittsburgh.edu Common Lisp LOOP Package
C02154 00631 ∂06-Feb-86 0828 DCP@SCRC-STONY-BROOK.ARPA eval'd macros (the other point of view)
C02158 00632 ∂06-Feb-86 0939 gls@THINK-AQUINAS.ARPA LISP standardisation
C02160 00633 ∂06-Feb-86 1318 Gregor.pa@Xerox.COM Re: loop macro
C02163 00634 ∂06-Feb-86 1320 RPG Please remover CSTACY from this mailing list
C02166 00635 ∂06-Feb-86 1329 RPG Loop Macro
C02168 00636 ∂06-Feb-86 1611 MMcM@SCRC-STONY-BROOK.ARPA LOOP again
C02169 00637 ∂06-Feb-86 1742 DLW@SCRC-STONY-BROOK.ARPA Re: loop macro
C02174 00638 ∂07-Feb-86 0814 hoey@nrl-aic Re: loop macro
C02181 00639 ∂07-Feb-86 0944 RPG
C02182 00640 ∂07-Feb-86 1313 Moon@SCRC-QUABBIN.ARPA loop macro
C02185 00641 ∂07-Feb-86 1322 Moon@SCRC-STONY-BROOK.ARPA loop macro
C02188 00642 ∂07-Feb-86 1521 DDYER@SCRC-STONY-BROOK.ARPA loop macro
C02192 00643 ∂08-Feb-86 2048 sean@cadre.dsl.pittsburgh.edu LOOP Macro code for Common Lisp
C02194 00644 ∂10-Feb-86 1145 Gregor.pa@Xerox.COM Compiling functions which appear inside top-level forms.
C02197 00645 ∂10-Feb-86 1215 @MIT-REAGAN.ARPA:KWH@MIT-AI.ARPA The return of UNSPECIAL
C02199 00646 ∂10-Feb-86 1245 FAHLMAN@C.CS.CMU.EDU Compiling functions which appear inside top-level forms.
C02202 00647 ∂10-Feb-86 1305 Gregor.pa@Xerox.COM Re: Compiling functions which appear inside top-level forms.
C02204 00648 ∂11-Feb-86 0811 kessler%utah-orion@utah-cs.arpa Car and Cdr of nil is nil
C02206 00649 ∂11-Feb-86 0915 FAHLMAN@C.CS.CMU.EDU Car and Cdr of nil is nil
C02209 00650 ∂11-Feb-86 0922 FAHLMAN@C.CS.CMU.EDU Compiling functions which appear inside top-level forms.
C02211 00651 ∂11-Feb-86 0941 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU code density as a function of elegance
C02217 00652 ∂11-Feb-86 1122 Bobrow.pa@Xerox.COM Re: Car and Cdr of nil is nil
C02219 00653 ∂11-Feb-86 1228 liz@brillig.umd.edu Re: loop macro
C02236 00654 ∂11-Feb-86 1234 hpfclp!diamant@hplabs.ARPA Re: intern
C02241 00655 ∂11-Feb-86 1443 masinter.pa@Xerox.COM Re: Car and Cdr of nil is nil
C02243 00656 ∂11-Feb-86 2008 HEDRICK@RED.RUTGERS.EDU problem with (CAR NIL) = NIL
C02245 00657 ∂12-Feb-86 0708 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: loop macro
C02247 00658 ∂12-Feb-86 0757 NGALL@G.BBN.COM Re: intern
C02256 00659 ∂12-Feb-86 1951 FAHLMAN@C.CS.CMU.EDU The return of UNSPECIAL
C02258 ENDMK
C⊗;
∂15-Sep-85 1441 MMcM@SCRC-STONY-BROOK.ARPA LAMBDA expression to the SATISFIES type specifier
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Sep 85 14:41:39 PDT
Received: from MERRIMACK.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 313991; Sun 15-Sep-85 17:38:27-EDT
Date: Sun, 15 Sep 85 17:42 EDT
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Subject: LAMBDA expression to the SATISFIES type specifier
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <850911163632.9.GLS@DESIDERIUS.THINK.COM>
Message-ID: <850915174204.1.MMCM@MERRIMACK.SCRC.Symbolics.COM>
Date: Wed, 11 Sep 85 16:36 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
The case I was worried about was
(defun foo (x y)
(declare (type (satisfies (lambda (q) (eq q y))) x))
...)
That doesn't seem to me substantially different from
(defun foo (x)
(flet ((foo-p (q) (eq q x)))
(let ((y x))
(declare (type (satisfies foo-p) y))
...)))
which the manual is quite clear on (it doesn't work). I have no
objection to the first example not working either. It seems that we
should allow LAMBDA expressions and be consistent about the lexical
environment for both functions and variables, presumably global.
∂16-Sep-85 1115 RAM@C.CS.CMU.EDU structure equality in slisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Sep 85 11:14:17 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 16 Sep 85 14:14:56-EDT
Date: Mon, 16 Sep 1985 14:14 EDT
Message-ID: <RAM.12143757965.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: David.Butcher@ML.RI.CMU.EDU
Cc: Gripe@ML.RI.CMU.EDU, Scott.Fahlman@C.CS.CMU.EDU,
Skef.Wholey@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Subject: structure equality in slisp
In-reply-to: Msg of 13 Sep 1985 14:23-EDT from David.Butcher at ML.RI.CMU.EDU
From: David.Butcher at ML.RI.CMU.EDU
To: Gripe at ML.RI.CMU.EDU
Re: structure equality in slisp
(equal (make-point) (make-point)) returned nil.
a point is just three slots containing a number each.
according to the book, things that have the same print name are equal.
so shouldn't equal work on structures?
Unfortunately, EQUAL is not a structural equality predicate. For
historical reasons, EQUAL on any atom other than a string (or a
bit-vector) is equivalent to EQL. Even worse, *there is no structural
equality predicate* in Common Lisp. You can use EQUALP, but then
comparisons of characters are case-insensitive. Yes, this is
misleading, confusing and inconsistent. I think it sucks. Flame
flame.
Rob
∂16-Sep-85 1251 REM%IMSSS.#Pup@SU-SCORE.ARPA EQUAL isn't really correct, I agree
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 12:51:35 PDT
Received: from IMSSS by Score with Pup; Mon 16 Sep 85 12:50:06-PDT
Date: 16 Sep 1985 1251-PDT
From: Rem@IMSSS
Subject: EQUAL isn't really correct, I agree
To: RAM%C.CS.CMU.EDU@SCORE
cc: COMMON-LISP%SU-AI@SCORE
Several months ago I came to the same conclusion, that none of the equality
predicates are correct for many structure-comparing operations, and I roughly
sketched out what would be better: a flexible structure-comparing function.
Basically you tell the function what kinds of primitive cells should be
STOP points and what should be recurse-through cells (the union of the
two sets should be the universe of data types, or at least should include
every kind of cell encountered in the task at hand). At STOP points, some
more primitive function is needed to perform the actual comparison, so you
tell the general function what primitive comparison function is to be used
at each STOP point. Also, at each recurse-through some method of mapping
all the components is needed, which would be implicit in the function
definition for built-in datatypes but may need to be described explicitly
for user-defined datatypes or for deliberately not recursing down certain
branches.
Typical variations on the usual EQUAL that would be supported trivially
by this method: Identifiers get compared by PNAME rather than EQ, thus
matching non-interned identifiers correctly. Numbers get compared with
fudge factor that is magnitude-dependent in unusual way. Recursion occurs
through the VALUE and PROPERTY-LIST of each identifier that is in the
FOO package but stops on other identifiers (hint, make identifiers STOP
points but define the comparison function at that point to look at the
package cell and explicitly call the super-equal function recursively
in some cases). ...
Once this super-general function is properly defined and implemented,
special cases can be described in a uniform way as canned arguments to
this function, and then can be handcoded more efficiently if desired.
In many cases there are oodles of special-case functions and nothing
properly general in CL currently. Perhaps general functions should be
defined and some of the special cases flushed, as such cases are recognized?
Super-general-EQUAL could be the first such super-general function?
-------
∂16-Sep-85 1456 hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA compiling anonymous functions
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 14:55:55 PDT
Received: from hplabs by csnet-relay.csnet id am07932; 16 Sep 85 17:52 EDT
Received: by HP-VENUS id AA23982; Mon, 16 Sep 85 11:13:54 pdt
Message-Id: <8509161813.AA23982@HP-VENUS>
Date: Monday, September 16, 1985 11:03:01
From: snyder%hplabs.csnet@CSNET-RELAY.ARPA
Subject: compiling anonymous functions
To: common-lisp@su-ai.arpa
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info: From (or Sender) name not authenticated.
I agree with Jonathan Rees that compilers should compile anonymous functions,
and that it is important that programmers be able to assume this behavior. I
also agree with Scott Fahlman that the best approach would be to require (or
at least strongly suggest) that compilers treat all compilable functions
equally. Thus, if a compiler compiles top-level defuns in a given
implementation, it must also compile other compilable function definitions as
well.
However, this notion depends on being able to come up with a clear definition
of "compilable function". Anyone have any suggestions on how to define this?
Can this notion be defined in a way that does not unduly restrict the
implementation? One thing that has bothered me in the definition of CL is the
limited definition of "top-level form" (page 66). I would suggest extending
it (recursively) to include forms directly nested in top-level occurrences of
LOCALLY, MACROLET, COMPILER-LET, EVAL-WHEN, and PROGN.
-------
∂17-Sep-85 0727 FAHLMAN@C.CS.CMU.EDU compiling anonymous functions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Sep 85 07:27:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 17 Sep 85 10:28:14-EDT
Date: Tue, 17 Sep 1985 10:28 EDT
Message-ID: <FAHLMAN.12143978847.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: snyder%hplabs.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: compiling anonymous functions
In-reply-to: Msg of 16 Sep 1985 11:03-EDT from snyder%hplabs.csnet at CSNET-RELAY.ARPA
Disclaimer: All of the following is a suggestion for how the language
specification might be improved, once we have a mechanism in place for
considering such improvements.
Clearly the whole section on top-level forms needs to be reconsidered
and tightened up. We got off on the wrong foot on that one, and never
recovered. Probably we should flush the whole notion of top-level forms
and just provide some rules about what the compiler does. We can
probably go ahead and assume that there is a compiler of some sort and
that it is written in Common Lisp without saying much about what code it
generates or how intensively it hacks things. What we need to specify
more clearly are which things get compiled (whatever that may mean) and
which forms are "seen" by the compiler in the sense of causing side
effects -- macro definitions, constant definitions, declarations, and
the like.
I think that the following are more or less standard practice now, and
should probably be required (or at least strongly suggested and assumed
by portable code libraries) at some future time:
1. Occurrences of (function (lambda ...)) within forms that are being
compiled are themselves compiled. So if a function definition is
(defun foo () (setf x #'(lambda () (mumble))))
then if we compile foo and then call it, X will contain a function
object that is compiled as if it had been a top-level defun. Note that
if you want to set X to an uncompiled expression, you can use '(lambda
...).
2. Embedded Defuns get compiled, roughly as if they were embedded
(setf (symbol-function <name>) (function (lambda ...))) forms.
We don't want to force users to write the long form in order to ensure
compilation. If an implementation has defun doing additional things,
such as maintaining data structures for the programming environment,
then it is up to the implementor to do the right thing when compiling
embedded Defuns, but the actual definition still should end up compiled.
3. "Random" Top-level forms (anything whose semantics are not special to
the compiler) are compiled and then executed at load time. So if a file
being compiled contains
(mumble ...)
it is compiled more or less as if it were
(defun <made-up-name> () (mumble ...))
(<made-up-name>)
The point is not to force all implementations to execute these things
fast at load time, though that is certainly a plus for any
implementation. The point of including this in the standard is to
standardize what happens when the random form contains constructs that
might have side effects on the compiler or sub-forms that might want to
be compiled. (This was discussed at some length before the manual came
out, but I don't think the manual currently takes a stand on this.)
So, if all the above were to become standard, a user could employ an
idiom like
(let ((x 0) (y 1024))
(defun foo () ...)
(defun bar () ...))
and be sure that FOO and BAR would be compiled, whatever that means for
a given implementaiton. I don't think this is guaranteed now, though it
is an idiom I use a lot.
I think that this subsumes Snyder's suggestions for extending the list
of forms whose interiors are considered to be "top-level", at least on
the issue of what gets compiled. The question of where you can put
PROCLAIM forms and the like might be more complicated.
-- Scott
∂18-Sep-85 0637 gls@THINK-AQUINAS.ARPA Franz -> Common Lisp
Received: from THINK.COM by SU-AI.ARPA with TCP; 18 Sep 85 06:37:11 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 18 Sep 85 09:37:58 edt
Date: Wed, 18 Sep 85 09:37 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Franz -> Common Lisp
To: leite@UCI-ICSD.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 17 Sep 85 19:52-EDT from Julio Leite <leite at uci-icsd>
Message-Id: <850918093747.1.GLS@DESIDERIUS.THINK.COM>
Date: 17 Sep 85 16:52:10 PDT (Tue)
From: Julio Leite <leite@uci-icsd>
Dear Mr Steele,
We at the Reuse Project, over University of California at
Irvine, are working in a conversion of a large prototype system
from Franz Lisp to Common Lisp.
We suppose that other people had this experience before,
and we would like to know if you know somebody who did it, and if
there are any references available.
We appreciate your attention, and be sure that any information
you may have will be very useful to us.
Thank you,
Julio Cesar Leite
UCI - ICS
Irvine,Ca 92717
leite@uci-icsd.arpa
ucbvax!ucivax!leite
I am forwarding this message to the common-lisp mailing list to
see what information we can come up with.
--Guy
∂18-Sep-85 0805 robbins@DEC-HUDSON Modification to LISTEN
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 08:04:37 PDT
Date: Wed, 18 Sep 85 11:07:13 EDT
From: robbins@DEC-HUDSON
Subject: Modification to LISTEN
To: common-lisp@su-ai
Cc: robbins@dec-hudson
I would like to have LISTEN return two values. The first value is the same as
it is now and the second value is true if end of file is encountered. The
new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR
and LISTEN.
(defun read-char-no-hang (&optional input-stream eof-error-p eof-value
recursive-p)
(multiple-value-bind (char-available-p eof-encountered-p)
(listen input-stream)
(cond (char-available-p
(read-char input-stream eof-error-p eof-value recursive-p))
(eof-encountered-p
(if eof-error-p (error ...) eof-value)))))
∂18-Sep-85 0956 FAHLMAN@C.CS.CMU.EDU Modification to LISTEN
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Sep 85 09:55:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Sep 85 12:56:44-EDT
Date: Wed, 18 Sep 1985 12:56 EDT
Message-ID: <FAHLMAN.12144268018.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: robbins@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Modification to LISTEN
In-reply-to: Msg of 18 Sep 1985 11:07-EDT from robbins at DEC-HUDSON
I would like to have LISTEN return two values. The first value is the same as
it is now and the second value is true if end of file is encountered. The
new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR
and LISTEN.
Looks like a good suggestion to me. It could be implemented in a
completely upward-compatible way.
-- Scott
∂18-Sep-85 1251 robbins@DEC-HUDSON Concatenated Stream Query
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 12:47:04 PDT
Date: Wed, 18 Sep 85 15:50:09 EDT
From: robbins@DEC-HUDSON
Subject: Concatenated Stream Query
To: common-lisp@su-ai
Cc: robbins
Given the following streams:
(setf stream-1 (make-string-input-stream "A line without a newline."))
(setf stream-2 (make-string-input-stream "Our generic second line."))
(setf stream-3 (make-concatenated-stream stream-1 stream-2))
What should (read-line stream-3) return, I can imagine two possibilities
"A line without a newline.Our generic second line." t
"A line without a newline." nil
-- Rich
∂18-Sep-85 1311 FAHLMAN@C.CS.CMU.EDU Concatenated Stream Query
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Sep 85 13:11:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Sep 85 16:12:08-EDT
Date: Wed, 18 Sep 1985 16:12 EDT
Message-ID: <FAHLMAN.12144303598.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: robbins@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Concatenated Stream Query
In-reply-to: Msg of 18 Sep 1985 15:50-EDT from robbins at DEC-HUDSON
(setf stream-1 (make-string-input-stream "A line without a newline."))
(setf stream-2 (make-string-input-stream "Our generic second line."))
(setf stream-3 (make-concatenated-stream stream-1 stream-2))
What should (read-line stream-3) return, I can imagine two possibilities
"A line without a newline.Our generic second line." t
"A line without a newline." nil
I think the first candidate is the obvious winner. I see nothing in the
manual that would support the existence of an implicit newline character
between the concatenated streams, and I don't think that this would be
desirable.
-- Scott
∂18-Sep-85 1318 @MIT-REAGAN.ARPA:Soley@MIT-MC.ARPA Concatenated Stream Query
Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 13:18:49 PDT
Received: from MIT-CHERRY by MIT-REAGAN via CHAOS with CHAOS-MAIL id 8171; Wed 18-Sep-85 16:20:33-EDT
Date: Wed, 18 Sep 85 16:18 EDT
From: Soley@MIT-MC.ARPA
Subject: Concatenated Stream Query
To: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 18 Sep 85 15:50-EDT from robbins at DEC-HUDSON
Message-ID: <850918161848.7.SOLEY@CHERRY.MIT>
Date: Wed, 18 Sep 85 15:50:09 EDT
From: robbins@DEC-HUDSON
Subject: Concatenated Stream Query
To: common-lisp@su-ai
Cc: robbins
Given the following streams:
(setf stream-1 (make-string-input-stream "A line without a newline."))
(setf stream-2 (make-string-input-stream "Our generic second line."))
(setf stream-3 (make-concatenated-stream stream-1 stream-2))
What should (read-line stream-3) return, I can imagine two possibilities
(1) "A line without a newline.Our generic second line." t
(2) "A line without a newline." nil
I think it definitely MUST return (1). Consider
(setf stream-1 (make-string-input-stream "A line without a newline.
"))
(setf stream-2 (make-string-input-stream "Our generic second line."))
(setf stream-3 (make-concatenated-stream stream-1 stream-2))
which should return (2). [The next (read-line stream-3) shouldn't
return "", but {"Our generic second line.", t}.
-- Richard
∂18-Sep-85 1415 gls@THINK-AQUINAS.ARPA Concatenated Stream Query
Received: from THINK.COM by SU-AI.ARPA with TCP; 18 Sep 85 14:14:37 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 18 Sep 85 17:15:28 edt
Date: Wed, 18 Sep 85 17:15 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Concatenated Stream Query
To: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <850918161848.7.SOLEY@CHERRY.MIT>
Message-Id: <850918171522.6.GLS@DESIDERIUS.THINK.COM>
I am in agreement with Fahlman and Soley on this matter. The manual
should be clearer on the point that the user of a concatenated stream
does not see any end-of-file indication when subsidiary streams other
than the last hit end of file. However, the manual certainly does not
support the implicit inclusion of any additional separator characters or
other such phenomena as one subsidiary stream ends and the next one
comes into use.
--Guy
∂18-Sep-85 1516 wagner@GSWD-VMS Erratum
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 15:16:22 PDT
Date: Wed, 18 Sep 85 17:16:00 CDT
From: wagner@GSWD-VMS
Subject: Erratum
To: common-lisp@su-ai.arpa
Cc: wagner
On the top of page 295 of CLtL, three examples are given for
the bit-array logic functions. The third example is
(bit-andc1 #*1100 #*1010) => #*0100
Given the definition of BIT-ANDC1 on page 294 ("and complement
argument1 with argument2"), this example is in error. Either
the function should be BIT-ANDC2, or the return value should
be #*0010.
Fran
∂18-Sep-85 1822 MMcM@SCRC-STONY-BROOK.ARPA Modification to LISTEN
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 18:22:22 PDT
Received: from MERRIMACK.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 316386; Wed 18-Sep-85 21:18:44-EDT
Date: Wed, 18 Sep 85 21:22 EDT
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Subject: Modification to LISTEN
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12144268018.BABYL@C.CS.CMU.EDU>
Message-ID: <850918212239.2.MMCM@MERRIMACK.SCRC.Symbolics.COM>
Date: Wed, 18 Sep 1985 12:56 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I would like to have LISTEN return two values. The first value is the same as
it is now and the second value is true if end of file is encountered. The
new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR
and LISTEN.
Looks like a good suggestion to me. It could be implemented in a
completely upward-compatible way.
In good lisp machine style, programs use both READ-CHAR-NO-HANG and
LISTEN. LISTEN is treated only as a (possibly spurious) wakeup.
Imagine a network stream interface, where LISTEN returns when some
packet-ready-for-reciept hardware flag gets set. READ-CHAR-NO-HANG
might return NIL if the packet that it reads out is damaged, out of
sequence, etc. The rule is that LISTEN is allowed to return T when
READ-CHAR-NO-HANG will return NIL, provided that READ-CHAR-NO-HANG will
tend to clear the spurious condition.
I'm not sure this advocates against the above proposal, but I do feel
that there is good reason for having both primitives.
∂19-Sep-85 0702 gls@THINK-AQUINAS.ARPA Erratum
Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Sep 85 07:02:43 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 19 Sep 85 10:03:33 edt
Date: Thu, 19 Sep 85 10:03 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Erratum
To: wagner@GSWD-VMS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 18 Sep 85 18:16-EDT from wagner at GSWD-VMS
Message-Id: <850919100326.1.GLS@DESIDERIUS.THINK.COM>
Date: Wed, 18 Sep 85 17:16:00 CDT
From: wagner@GSWD-VMS
On the top of page 295 of CLtL, three examples are given for
the bit-array logic functions. The third example is
(bit-andc1 #*1100 #*1010) => #*0100
Given the definition of BIT-ANDC1 on page 294 ("and complement
argument1 with argument2"), this example is in error. Either
the function should be BIT-ANDC2, or the return value should
be #*0010.
Fran
Right you are. Thanks.
--Guy
∂19-Sep-85 1626 MLY%MIT-OZ@MIT-MC.ARPA Returning additional values from advertised functions
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Sep 85 16:25:52 PDT
Date: Thu 19 Sep 85 19:27:24-EDT
From: Richard Mlynarik
Subject: Returning additional values from advertised functions
Sender: MLY%MIT-OZ@MIT-MC.ARPA
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Reply-To: MLY@MIT-OZ
In-Reply-To: <FAHLMAN.12144268018.BABYL@C.CS.CMU.EDU>
Message-ID: <12144601298.71.MLY@MIT-OZ>
Date: Wed, 18 Sep 1985 12:56 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: robbins@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Modification to LISTEN
In-reply-to: Msg of 18 Sep 1985 11:07-EDT from robbins at DEC-HUDSON
I would like to have LISTEN return two values. [...]
Looks like a good suggestion to me. It could be implemented in a
completely upward-compatible way.
I am a little worried about this answer. The existence of
the multiple-value-call special form means that no such change can
truly be made upward-compatibly. The lisp I maintain has a number
of functions which return useful, additional values (though usually
somewhat too implementation-specific or marginal to be advocated as a
an enhancement for "official" cl) beyond those specified by GSSB, and
I am somewhat loathe to flush them simply for compatibility when I am
sure that most receivers of multiple values are either
multiple-value-bind/setq's.
I remember that at the time of the initial discussion of the cl
multiple-value scheme there were a number of people (kmp stands out
most distinctly in my memory) who advocated as rigorous checking in
receiving multiple values from calls as in receiving arguments to
calls. Perhaps they were right.
As it stands, I think that anybody using multiple-value-call is
except in very constrained situations is probably Courting Lossage
Just a point to bear in mind....
[BTW I have been inconvenienced several times recently by the fact the
multiple-value-setq is not multiple-value-setf. This is a somewhat
curious shortcoming, especially now that the All-New Fashion in lisp
code seems to be to entirely eschew setq in favour of setf]
-------
∂19-Sep-85 1758 bobrow.pa@Xerox.ARPA Arguments and values to get.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Sep 85 17:58:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 85 17:43:45 PDT
Date: 19 Sep 85 16:39 PDT
Sender: bobrow.pa@Xerox.ARPA
Subject: Arguments and values to get.
To: Common-Lisp@SU-AI.ARPA
cc: cl-object-oriented-programming@su-ai.ARPA
From: Gregor.pa@Xerox.ARPA
Message-ID: <850919-174345-1059@Xerox>
This (admittedly minor) question came up while we were writing up some
of the CommonLoops metaclass protocols.
Why does Common-Lisp GET take a default-value argument instead of
returning a second value indicating whether the property actually
exists?
Originally we had wanted to make CommonLoops' internal slot-access
function return a second value saying whether or not the slot-existed
but we ended up changing it to be more like GET.
∂19-Sep-85 1819 FAHLMAN@C.CS.CMU.EDU Arguments and values to get.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Sep 85 18:19:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 19 Sep 85 21:19:45-EDT
Date: Thu, 19 Sep 1985 21:19 EDT
Message-ID: <FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor.pa@XEROX.ARPA
Cc: cl-object-oriented-programming@SU-AI.ARPA, Common-Lisp@SU-AI.ARPA
Subject: Arguments and values to get.
In-reply-to: Msg of 19 Sep 1985 19:39-EDT from Gregor.pa at Xerox.ARPA
Why does Common-Lisp GET take a default-value argument instead of
returning a second value indicating whether the property actually
exists?
The default argument is useful in some cases, but admittedly is a bit
inelegant -- if you want to know for sure whether a value was found, you
have to be careful to choose some default argument that couldn't
possibly be stored in any property list. The reasoning (If I recall it
correctly) was that this occasional creation of a unique default is less
hassle than having to write an ugly multiple-value-bind every time we
want to return a default value in the property-not-found case. I'm not
sure I believe that any more.
-- Scott
∂20-Sep-85 0649 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Erratum on p.107Subject:
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 06:49:52 PDT
Received: from tektronix by csnet-relay.csnet id ae04939; 20 Sep 85 9:43 EDT
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Fcc: cl-mail
Received: from tekchips by tektronix with smtp ; 19 Sep 85 10:13:47 PDT
Date: Thursday, 19 Sep 85 10:09:07 PDT
Subject: Erratum on p.107Subject:
On p.107 at the bottom of the page where the setq's and apply's occur:
Replace respectively:
(setq f '+) ... and
(apply 'cons ...)
BY
(setq f #'+) ... and
(apply #'cons ...)
This will improve consistency of syntax for function symbols.
Sridhar
...!tektronix!tekchips!sridhar
∂20-Sep-85 0651 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA erratum: logic error on p.125
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 06:51:02 PDT
Received: from tektronix by csnet-relay.csnet id aa04939; 20 Sep 85 9:46 EDT
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Fcc: cl-mail
Received: from tekchips by tektronix with smtp ; 19 Sep 85 18:03:46 PDT
Date: Thursday, 19 Sep 85 17:58:26 PDT
Subject: erratum: logic error on p.125
On p.125 about the middle of the page in the ribcage-lookup function
in the scope of the second do:
REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v)))
[the cdar is replaced by cadar]
∂20-Sep-85 0709 KMP@SCRC-STONY-BROOK.ARPA Arguments and values to get.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 07:08:53 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317574; Fri 20-Sep-85 10:09:02-EDT
Date: Fri, 20 Sep 85 10:09 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Arguments and values to get.
To: Fahlman@C.CS.CMU.EDU, Gregor.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>
References: Msg of 19 Sep 85 19:39-EDT from Gregor.pa at Xerox.ARPA
Message-ID: <850920100928.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 19 Sep 1985 21:19 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor.pa@XEROX.ARPA
In-reply-to: Msg of 19 Sep 1985 19:39-EDT from Gregor.pa at Xerox.ARPA
Why does Common-Lisp GET take a default-value argument instead of
returning a second value indicating whether the property actually
exists?
The default argument is useful in some cases, but admittedly is a bit
inelegant -- if you want to know for sure whether a value was found, you
have to be careful to choose some default argument that couldn't
possibly be stored in any property list. The reasoning (If I recall it
correctly) was that this occasional creation of a unique default is less
hassle than having to write an ugly multiple-value-bind every time we
want to return a default value in the property-not-found case. I'm not
sure I believe that any more.
-- Scott
It would be reasonable to propose a more-or-less upward-compatible extension
to GET (for CL86 or whatever) which provided that GET both accepted a argument
specifying the default to be used -and- returned two values (one the result,
the second a boolean saying whether the argument had been defaulted).
∂20-Sep-85 0737 DLW@SCRC-STONY-BROOK.ARPA erratum: logic error on p.125
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 07:37:32 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317626; Fri 20-Sep-85 10:37:37-EDT
Date: Fri, 20 Sep 85 10:35 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: erratum: logic error on p.125
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: The message of 19 Sep 85 20:58-EDT from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-ID: <850920103525.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Thursday, 19 Sep 85 17:58:26 PDT
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
On p.125 about the middle of the page in the ribcage-lookup function
in the scope of the second do:
REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v)))
[the cdar is replaced by cadar]
I don't think so. It appears to me that the example is correct. Read
the text above the example carefully. It says "...the cdr of each cons
is a list...". That is, the elements of the top-level lists are conses,
not two-element lists.
There is, however, a picotypo in this example: the introductory text
says "...suppose that ENV holds a list of conses...", but the example
doesn't use the variable ENV anywhere. (Do I get the "picky, picky"
award for submitting the most trivial erratum?)
∂20-Sep-85 0741 DLW@SCRC-STONY-BROOK.ARPA Erratum on p.107Subject:
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 07:40:56 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317634; Fri 20-Sep-85 10:40:00-EDT
Date: Fri, 20 Sep 85 10:37 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Erratum on p.107Subject:
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: The message of 19 Sep 85 13:09-EDT from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-ID: <850920103750.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Thursday, 19 Sep 85 10:09:07 PDT
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
On p.107 at the bottom of the page where the setq's and apply's occur:
Replace respectively:
(setq f '+) ... and
(apply 'cons ...)
BY
(setq f #'+) ... and
(apply #'cons ...)
This will improve consistency of syntax for function symbols.
This is not an error. Read the textual description of "apply". The
description explicitly mentions that you can use a symbol as the first
argument to apply, and gives some rules about doing so. The examples
that you're referring to were included to illustrate the use of symbols
as functions. That is, the number-signs were omitted intentionally.
∂20-Sep-85 1215 gls@THINK-AQUINAS.ARPA Erratum on p.107Subject:
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85 12:15:18 PDT
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:16:10 edt
Date: Fri, 20 Sep 85 15:16 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Erratum on p.107Subject:
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 19 Sep 85 13:09-EDT from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <850920151620.1.GLS@JEHOSEPHAT.THINK.COM>
Date: Thursday, 19 Sep 85 10:09:07 PDT
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
On p.107 at the bottom of the page where the setq's and apply's occur:
Replace respectively:
(setq f '+) ... and
(apply 'cons ...)
BY
(setq f #'+) ... and
(apply #'cons ...)
This will improve consistency of syntax for function symbols.
Sridhar
...!tektronix!tekchips!sridhar
Thank you for your comment. The examples are indeed inconsistent as to
style, but all are legitimate. The cases without #' were intended to
demonstrate that it is legitimate to give a symbol to APPLY, and it will
implicitly "dereference" the symbol by looking at its global functional
value. Some remarks to this effect shou;ld be added in the prose to
elucidate this. Depending on one's purpose, one may wish to use ' or #'.
--Guy
∂20-Sep-85 1219 gls@THINK-AQUINAS.ARPA erratum: logic error on p.125
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85 12:19:48 PDT
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:20:46 edt
Date: Fri, 20 Sep 85 15:20 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: erratum: logic error on p.125
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 19 Sep 85 20:58-EDT from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <850920152057.2.GLS@JEHOSEPHAT.THINK.COM>
Date: Thursday, 19 Sep 85 17:58:26 PDT
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
On p.125 about the middle of the page in the ribcage-lookup function
in the scope of the second do:
REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v)))
[the cdar is replaced by cadar]
Thank you for your comment. The code as it stands is consistent with
the description in the preceding paragraph, and in particular with the
remark that the ribcage resembles an association list.
There are two styles of coding that I have observed people using in LISP
code with respect to associating lists. One is the traditional a-list:
((A . B) (C . D) (E . F))
The other is similar, but uses 2-lists instead of dotted pairs:
((A B) (C D) (E F))
The first saves CONS cells, but is more complicated to print. The
second looks neater, but takes more memory space and requires extra CAR
operations to access. I think this latter style has been promulgated by
the SCHEME community in particular.
Either is fine, but the example was intended to use the first style of
list. Perhaps more explanation is needed for this example.
--Guy
∂20-Sep-85 1221 gls@THINK-AQUINAS.ARPA erratum: logic error on p.125
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85 12:21:31 PDT
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:22:35 edt
Date: Fri, 20 Sep 85 15:22 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: erratum: logic error on p.125
To: DLW@SCRC-QUABBIN.ARPA, sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <850920103525.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <850920152246.3.GLS@JEHOSEPHAT.THINK.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Fri, 20 Sep 85 10:35 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
....
There is, however, a picotypo in this example: the introductory text
says "...suppose that ENV holds a list of conses...", but the example
doesn't use the variable ENV anywhere. (Do I get the "picky, picky"
award for submitting the most trivial erratum?)
It's as legitimate a typo as anything else. Do I get an award for
generating the trivial error in the first place?
--Guy
∂20-Sep-85 1348 mips!escargot.earl@glacier Arguments and values to get.
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 13:48:14 PDT
Received: by glacier with Sendmail; Fri, 20 Sep 85 13:48:20 pdt
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
id AA00574; Fri, 20 Sep 85 12:21:37 pdt
Received: by escargot.UUCP (4.12/4.7)
id AA09473; Fri, 20 Sep 85 13:05:36 pdt
Date: Fri, 20 Sep 85 13:05:36 pdt
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8509202005.AA09473@escargot.UUCP>
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: "Scott E. Fahlman"'s message of Thu, 19 Sep 1985 21:19 EDT
Subject: Arguments and values to get.
When you really need to know whether the value was present in the
property list or not, I agree that the &OPTIONAL default argument to
GET is painful. Other times, however, it is exactly what you want
(you really just want a default value), and implementing the default
from a second return value is painful. Thus the current definition
is not a mistake, although it may not be featureful enough.
∂20-Sep-85 1702 FAHLMAN@C.CS.CMU.EDU EQUAL isn't really correct, I agree
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Sep 85 19:37:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 17 Sep 85 22:38:35-EDT
Date: Tue, 17 Sep 1985 22:38 EDT
Message-ID: <FAHLMAN.12144111807.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Rem@MIT-MC.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: EQUAL isn't really correct, I agree
Comment: Remailed at SU-AI after delay caused by distribution list problem.
Once this super-general function is properly defined and implemented,
special cases can be described in a uniform way as canned arguments to
this function, and then can be handcoded more efficiently if desired.
In many cases there are oodles of special-case functions and nothing
properly general in CL currently. Perhaps general functions should be
defined and some of the special cases flushed, as such cases are recognized?
Super-general-EQUAL could be the first such super-general function?
Gee, maybe we should provide COND and DEFMACRO and let the user code up
whatever equality predicate he really wants. Would that be general
enough? Oops, we did that already...
But seriously, it is a very serious step to put in some piece of
special-purpose programmable mechanism for some random part of the
language. This might be called for in the case of iteration (if we
could ever agree on a syntax for something like the loop macro), but I
can't see any compelling reason to put in yet another load of hair for a
customizable equality predicate. If there are kinds of equality that
are FREQUENTLY needed and are not currently provided (and I think there
are a couple) we should consider adding these, but let's not go
overboard (yet again).
-- Scott
∂20-Sep-85 2312 GSB@MIT-MC.ARPA Modification to LISTEN
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 23:12:17 PDT
Date: Sat, 21 Sep 85 02:12:53 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: Modification to LISTEN
To: robbins@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].653117.850921.GSB>
Aside from some already mentioned reasons, one can always do
(defun listen (&optional (input-stream *standard-input*))
(let ((char (read-char-no-hang stream nil nil)))
(cond ((null char) nil)
(t (unread-char char) t))))
instead of the other way around, without changing the definition of
anything.
∂21-Sep-85 0729 robbins@DEC-HUDSON LISTEN Proposal
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Sep 85 07:29:05 PDT
Date: Sat, 21 Sep 85 10:31:45 EDT
From: robbins@DEC-HUDSON
Subject: LISTEN Proposal
To: common-lisp@su-ai
Cc: GSB@MIT-MC
Obviously there is no pressing need to do anything to the current
definition of LISTEN. However, I think that it is kind of strange to
have a pair of similar functions whose definitions are just inconsistent
enough so that the "intuitive" implementation of one fails.
... one can always do
(defun listen (&optional (input-stream *standard-input*))
(let ((char (read-char-no-hang stream nil nil)))
(cond ((null char) nil)
(t (unread-char char) t))))
I agree that this will work just fine. Am I the only one who objects to
the extra IO implicit in this definition?
From the definition of READ-CHAR-NO-HANG CLtL page 380:
"LISTEN does not distinguish between end-of-file and no
input being available, whereas READ-CHAR-NO-HANG does
make that distinction returning EOF-VALUE at end-of-file ..."
Is there a good reason for this seemingly gratuitous inconsistency in
the language?
∂21-Sep-85 1350 edsel!jim@su-navajo.arpa listen, etc.
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 21 Sep 85 13:50:13 PDT
Received: by su-navajo.arpa with Sendmail; Sat, 21 Sep 85 13:47:40 pdt
Received: by edsel.uucp (2.0/SMI-2.0)
id AA28888; Sat, 21 Sep 85 13:41:51 pdt
Date: Sat, 21 Sep 85 13:41:51 pdt
From: edsel!jim@su-navajo.arpa (Jim McDonald)
Message-Id: <8509212041.AA28888@edsel.uucp>
To: navajo!common-lisp@su-ai
Subject: listen, etc.
CLtL currently says "The predicate LISTEN is true if there is a
character immediately available from input-stream, and false if not."
This precludes any reasonable use for LISTEN on non-character streams,
which seems to me to be a flaw. It is not hard to imagine a program that
loads binary data from a network while carrying on other tasks (like
responding to the user!) during the pauses between arrival of packets.
There might even be non-character, non-byte streams that act as pipes
or queues of complex objects. It would be useful if LISTEN could be
used to poll arbitrary input streams, even if many such applications
might be handled better by interrupt-driven routines.
Are there any objections to changing the definition to say "The predicate
LISTEN is true if a transaction datum is immediately available from
input-stream, and false if not."?
Note that with this revised definition, READ-CHAR-NO-HANG and potential,
analogous, routines such as READ-BYTE-NO-HANG would be too specialized
to define LISTEN. Thus as long as the change I propose is not completely
ruled out, it would be premature to define LISTEN in terms of
READ-CHAR-NO-HANG.
---
In a similar vein, the book groups CLEAR-INPUT among those routines that
act on character streams, but the definition itself does not seem to imply
that the stream must be a character stream. Likewise, FINISH-OUTPUT,
FORCE-OUTPUT, and CLEAR-OUTPUT are grouped with functions on character
streams, but seem to be reasonable for arbitrary output streams.
I propose that such routines should work for all streams with the
appropriate direction. Could someone involved with their definition
clarify this?
---
Would READ-DATUM, PEEK-DATUM, READ-DATUM-NO-HANG, and UNWRITE-DATUM be
appropriate stream functions, with -CHAR- and -BYTE- forms available for
clarity and/or efficiency?
---
Finally, have there been any proposals for mechanisms to create
non-character, non-byte streams, and if not, is it due to lack of
interest or lack of agreement? I think a good queueing primitive
would find many uses.
Jim McDonald
∂22-Sep-85 1814 GJC@MIT-MC.ARPA Lisp Test
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Sep 85 18:14:30 PDT
Date: Sun, 22 Sep 85 21:15:09 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject: Lisp Test
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].654263.850922.GJC>
Here are some questions I'm thinking about putting into a lisp teasers
test. In order so that I can get an idea of how difficult the questions
are, please reply with your answers. Take no longer than 4 minutes.
What are the return values of the following expressions when evaluated:
[1] (let ((x (list nil))) (car x))
[2] (let ((x (list nil))) (setf (car x) 5) (car x))
[3] (flet ((g () 5)) (g))
[4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))
∂22-Sep-85 1846 FAHLMAN@C.CS.CMU.EDU Lisp Test
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Sep 85 18:45:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Sep 85 21:46:04-EDT
Date: Sun, 22 Sep 1985 21:46 EDT
Message-ID: <FAHLMAN.12145412963.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Lisp Test
In-reply-to: Msg of 22 Sep 1985 21:15-EDT from George J. Carrette <GJC at MIT-MC.ARPA>
[1] (let ((x (list nil))) (car x)) nil
[2] (let ((x (list nil))) (setf (car x) 5) (car x)) 5
[3] (flet ((g () 5)) (g)) 5
[4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g)) error
The error is "FUNCTION not a SETF-able form." or words to that effect.
If in 4 you meant to setf (symbol-function 'g), then the answer is 5.
-- Scott
∂22-Sep-85 1848 FAHLMAN@C.CS.CMU.EDU Lisp Test -- oops!
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Sep 85 18:46:32 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Sep 85 21:47:25-EDT
Date: Sun, 22 Sep 1985 21:47 EDT
Message-ID: <FAHLMAN.12145413212.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Lisp Test -- oops!
In-reply-to: Msg of 22 Sep 1985 21:15-EDT from George J. Carrette <GJC at MIT-MC.ARPA>
Sorry, I meant to send that just to GJC and not to the whole list, but I
hit the wrong key. Hope I didn't spoil the fun.
-- Scott
∂23-Sep-85 1131 DDYER@SCRC-QUABBIN.ARPA Lisp Test
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 Sep 85 11:31:38 PDT
Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 204097; Mon 23-Sep-85 14:31:34-EDT
Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 139578; Mon 23-Sep-85 11:36:30-PDT
Date: Mon, 23 Sep 85 11:33 PDT
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: Lisp Test
To: George J. Carrette <GJC@MIT-MC.ARPA>, common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <[MIT-MC.ARPA].654263.850922.GJC>
Message-ID: <850923113338.7.DDYER@PURPLE.SWW.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Sun, 22 Sep 85 21:15:09 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Here are some questions I'm thinking about putting into a lisp teasers
test. In order so that I can get an idea of how difficult the questions
are, please reply with your answers. Take no longer than 4 minutes.
What are the return values of the following expressions when evaluated:
[1] (let ((x (list nil))) (car x))
nil
[2] (let ((x (list nil))) (setf (car x) 5) (car x))
5
[3] (flet ((g () 5)) (g))
5
[4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))
7
Except, it actually returns 5, and the global function (g) returns 7.
This has to be a bug.
∂23-Sep-85 1425 gls@THINK-AQUINAS.ARPA Public relations: second time around
Received: from THINK.COM by SU-AI.ARPA with TCP; 23 Sep 85 14:25:05 PDT
Received: from sebastian by GODOT.THINK.COM via CHAOS; Mon, 23 Sep 85 17:26:11 edt
Date: Mon, 23 Sep 85 17:25 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Public relations: second time around
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <850923172551.4.GLS@SEBASTIAN.THINK.COM>
This is a retransmission of an earlier note requesting information on
Common Lisp implementations. So far I have gotten NO replies. Am I to
assume that no one wants to be mentioned when I talk in Japan?
I could make up a list without any help, but it would probably have
holes and stale information in it. I really do want to use accurate
information, but I need this information by Thursday, September 26, to
be useful. Please help me out.
--Thanks,
Guy
----------------------------------------------------------------------
I am seeking summary data about existing Common Lisp implementations.
I am planning to travel to Japan in October and give seminars there
about Common Lisp. (This is in connection with the recent publication
of the Japanese translation by Dr. Masayuki Ida of the Common Lisp
manual.) While most of the content will be technical, I will surely be
asked about existing implementations, particularly those in the United
States. I would like to be accurate and complete, and so I need your
help.
If you are supporting an implementation of Common Lisp (or a subset),
could you please send me the following information about it?
(1) Name of implementation
(2) Name of support organization (implementor, vendor, or whatever)
(3) Hardware configuration(s) and operating system(s)
(4) Available now? If not, when?
(5) Full Common Lisp or subset?
(6) If a subset, what's missing? Will missing parts be implemented later?
(7) (optional) Address of support organization or other contact
(8) (optional) Any interesting language extensions or
applications packages you want mentioned?
This won't be a sales presentation, and I won't recommend any
implementation over any other, so I'm not interested in prices.
(Actually, I am, but if you send me price information I won't use it in
these seminars.) I intend simply to present a list, both on overhead
transparencies during my talk and in hardcopy form. I think it would
give Common Lisp a boost to have a nice long list of implementors to
show off.
I have also requested my contacts in Japan to prepare a similar list of
Japanese implementations, and I will report any information received to
this mailing list.
Thank you for your help.
--Guy
∂24-Sep-85 2129 RPG Meeting
To: common-lisp@SU-AI.ARPA
It being a year since the last Common Lisp Meeting, I would like to
propose a second meeting. To be accurate, DARPA has suggested that
someone ought to propose a second meeting. I think we are in a position
to finally settle the following questions:
1) How shall the charter be constructed for Common Lisp?
2) Are we all agreed that the minor changes to Common Lisp,
especially the errata, are to be part of the Common Lisp
standard?
3) Shall we adopt an error handling facility?
I think we can have reasonable discussions on the following:
1) How shall windows be handled?
2) Shall we agree to experiment with CommonLoops (appropriately
named) as the object-oriented programming paradigm?
There are several new topics that deserve discussion:
1) What shall be our approach to ANSI standardization.
2) How shall we handle changes to the Common Lisp book?
(This topic includes copyright questions that have come up).
I have some thoughts as to the organization of the meeting and other
administrative details. First, the meeting would best be held on the East
Coast - it was held in Monterey, California last year. Second, attendance
should be limited to 2 or 3 representatives from each organization. This
rule will help us to keep the discussions from getting out of control. I
would be willing to let more people attend the meeting, but restrict
commentary to a small number of people. If only 2 people are allowed, we
should probably leave the actual decisions to a written ballot after the
meeting, with advisory votes at the meeting.
Third, the meeting should be held at a location that is easily accessible.
Several possibilities that come to mind are Washington, New York, and
Boston. Fourth, I think that the meeting should be held towards the end
of November, so that there is plenty of time to arrange schedules. Fifth,
I think we should decide on the above before the end of September.
Please mail to me (RPG@SAIL) your responses to these ideas, and I will
attempt to coalesce them into some sort of decision or into a condensed
set of issues for all of us to consider - I want to keep the discussion
about the meeting streamlined.
-rpg-
∂24-Sep-85 2359 TIM@MIT-MC.ARPA Lisp Test
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 23:57:56 PDT
Date: Wed, 25 Sep 85 02:59:30 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Lisp Test
To: GJC@MIT-MC.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Sun 22 Sep 85 21:15:09 EDT from George J. Carrette <GJC at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].658760.850925.TIM>
Date: Sun, 22 Sep 85 21:15:09 EDT
From: George J. Carrette <GJC at MIT-MC.ARPA>
[4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))
George,
I had been wondering about this for a while. I thought that FUNCTION
might be magic, but (SETF (FUNCTION ...) ...) does not appear to be
defined in CLtL. Perhaps you meant to use SYMBOL-FUNCTION instead.
If so, it would indeed make a good teaser for testing to see if people
had carefully read page 90.
Folks,
Does Common Lisp provide any way to side effect "lexical function cells"
such as G above?
∂25-Sep-85 0946 KESSLER@UTAH-20.ARPA Argument Type Mismatch Errors
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 09:46:08 PDT
Date: Wed 25 Sep 85 10:46:19-MDT
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Subject: Argument Type Mismatch Errors
To: common-lisp@SU-AI.ARPA
Message-ID: <12146101145.24.KESSLER@UTAH-20.ARPA>
Is there any agreement as to what a CL system should do when a type
error occurs? What I am thinking about are things like append, which
specifies that all arguments (except) the last are to be lists. If one
element is not a list should an error occur? In Hedrick's Dec-20 CL, it
does cause an error. Since the standard doesn't say that an error is
required, couldn't one write a legal implementation of CL where it ignores
the offending argument? Along similar lines is our PCLS implementation of the
package system. Packages are implemented as defstructs, so if a non
package argument is passed to a function that expect the package, our
system currently causes an error as it tries to access a field in the
defstruct (defstructs are vectors so the error message says something like
illegal to index non vector `bar'). At least in this case it gets an error,
although one that could be confusing to the programmer. [The obvious
reason for not type checking that the argument is in fact a package
defstruct is because of efficiency.]
Thanks.
Bob.
-------
∂25-Sep-85 1132 smh@mit-ems.ARPA Re: Argument Type Mismatch Errors
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 11:31:16 PDT
Received: by mit-ems.ARPA (4.12/4.8) id AA07704; Wed, 25 Sep 85 14:31:20 edt
Date: Wed, 25 Sep 85 14:31:20 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509251831.AA07704@mit-ems.ARPA>
To: KESSLER@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
Subject: Re: Argument Type Mismatch Errors
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Subject: Argument Type Mismatch Errors
Since the standard doesn't say that an error is required,
couldn't one write a legal implementation of CL where it
ignores the offending argument?
CLtL section 1.2.4 (pg.5) precisely defines what is required of an
implementation. The short answer to your question is, yes, you can
write a valid CL with an append that ignores invalid arguments, but you
*cannot* write a valid CL program that exploits this behaviour!
Unofficially: An implementation obviously should detect and signal
errors when convenient. The primary force against always doing so is
run-time efficiency. Personally, I feel that once an implementation
detects an error such as an inappropriate argument type, it should
always signal the error rather than silently proceeding. There's no
reason not to signal the error, assuming the price of detecting it has
already been paid.
∂25-Sep-85 1153 smh@mit-ems.ARPA missing function: typep-type-p
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 11:53:05 PDT
Received: by mit-ems.ARPA (4.12/4.8) id AA07882; Wed, 25 Sep 85 14:53:27 edt
Date: Wed, 25 Sep 85 14:53:27 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509251853.AA07882@mit-ems.ARPA>
To: common-lisp@su-ai
Subject: missing function: typep-type-p
It is an error if the "typep" and "subtypep" functions are passed
something other than a valid type specifier. The set of valid type
specifiers is extensible by defstruct (and possibly by some proposed
active object extensions). However, there appears to be no way to
determine if an arbitrary expression is a valid second argument to
typep (or declaration type, or first argument to the "the" special
form). Sometimes one might need to know -- for instance, to determine
if a "foo" defstruct has ever been defined. I can think of no
non-implementation-dependent way to find out. By the way, typep is not
required to signal an error if passed an invalid type specifier, so it
might return t, or nil, or whatever.
I suggest a new predicate with an ugly name:
typep-type-p expr [Function]
The expr can be anything at all, and this predicate is true
iff expr is a valid type specifier in the current Lisp world.
∂25-Sep-85 1438 gls@THINK-AQUINAS.ARPA Public relations: data so far
Received: from THINK.COM by SU-AI.ARPA with TCP; 25 Sep 85 14:38:21 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 25 Sep 85 17:39:13 edt
Date: Wed, 25 Sep 85 17:39 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Public relations: data so far
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <850925173916.5.GLS@DESIDERIUS.THINK.COM>
I have collated the data given to me so far about Common Lisp
implementations and have put it into a more-or-less standardized format.
The data appears at the end of this message. Some of the information
was so incomplete that I could not include it here (though that same
information was useful in giving me leads to chase down further).
Implementations that I believe to exist in some form but that are not
given below, and which I would like to have data on: DEC VAX LISP; Data
General; Texas Instruments for Explorer; Intermetrics for IBM 370;
Symbolics; LMI; Franz, Inc., for machines other than Tektronix; Gold
Hill for IBM PC; MIT NIL for VAX. Please send data if you can!
Thanks to all who have responded. Can you please check my summaries
for accuracy and completeness?
Some respondents sent rather long descriptions that are very interesting
but won't fit on a slide. I would be happy to redistribute these long
responses to this mailing list, but perhaps it would be more appropriate
for the original senders to do so if they wish. (One or two messages
contained some data that might be sensitive in the near future, and so I
don't want to redistribute the messages wholesale without permission.)
--Guy
----------------------------------------------------------------
The data given in my talk will be preceded by a notice such
as the following:
The following Common Lisp implementation data is
provided for purposes of information only. It is
accurate and complete to the best of my knowledge,
but I (Guy Steele) cannot guarantee that it is
correct. I do not speak for or represent the
implementors and vendors in any way. If you wish
further information, please contact the vendors at
the addresses given.
----------------------------------------------------------------
[I realize that the formatting is ugly. I am going to fix it up using
TeX or something.]
Name: Portable Common Lisp Subset (PCLS, ``pickles'')
Supported by: University of Utah
Hardware and operating system: Sun, Apollo, HP, Vax/VMS, Vax/Unix, Dec-20, IBM-370/CMS, Cray, Gould
Availability: Spring 1986
Full language or subset: subset
Missing features: rational and complex numbers, characters, closures.
Remarks: PCLS is a subset of Common Lisp that will run in any PSL implementation.
Contact:
Prof. Robert R. Kessler
3160 M.E.B.
Department of Computer Science
University of Utah
Salt Lake City, Utah 84112
USA
Name: Gould Common Lisp
Supported by: Gould Electronics, Computer Systems Division
Hardware and operating system: Gould Powernode 9000 and 6000 series with UTX-32 (UNIX 4.2BSD with System V enhancements)
Availability: 1986
Full language or subset: full
Remarks: Ability to call C and Fortran functions from within Lisp.
Contact:
International Sales and Marketing
Gould Computer Systems Division
6901 W. Sunrise Blvd.
Fort Lauderdale, Florida 33313
USA
Name: Hewlett Packard Development Environment for Common Lisp
Supported by: Hewlett Packard, Fort Collins Systems Division
Hardware and operating system: HP 9000 models 310 (68010-based) and 320 (68020-based) with HP-UX (UNIX System V plus Berkeley enhancements)
Availability: January 1986
Full language or subset: full
Remarks: EMACS-like editor with browsers. Support for object-oriented programming.
Not based on CMU implementation.
Contact:
Mike Bacco, AI Products Manager (marketing) or Roger Ison, Project Manager (technical)
Ft. Collins Systems Division
Hewlett Packard Company
Ft. Collins, Colorado 80525
USA
(303) 226-3800
Name: TekCommonLisp
Implemented by: Tektronix, Inc., in conjunction with Franz, Inc.
Supported by: Tektronix, Inc.
Hardware and operating system: Tektronix 4404 (68010-based), 4405, 4406 (68020-based)
Availability: First quarter 1986
Full language or subset: full
Remarks: Flavors, calls to functions in other programming languages, Lisp structure editor, and other utilities.
Contact:
Mike Taylor
Marketing Manager
Artificial Intelligence Machines Group
Tektronix Inc.
PO Box 1000, MS 60-405
Wilsonville, Oregon 97070
USA
(503) 685-2942
Franz, Inc.
1141 Harbor Bay Parkway,
Alameda, California 94501
USA
(415) 769-5656.
Name: ETI Lisp (formerly called Spice Lisp)
Implemented by: Carnegie-Mellon University
Supported by: Expert Technologies, Inc.
Hardware and operating system: PERQ with Accent version S6 (release 2)
Availability: now
Full language or subset: subset
Missing features: complex numbers
Remarks: Flavors, remote process spawning, remote procedure calls, HEMLOCK (EMACS-like editor).
Contact:
Joseph R. Ginder
Expert Technologies, Inc.
461 Melwood Avenue
Pittsburgh, Pennsylvania 15213
USA
For the UK and Europe:
Roger Vinnecombe
Advent, Ltd.
12 The Business Centre
Molley Millars Lane
Wokingham, Berkshire
RG11 2RT
ENGLAND
Name: Sun Common Lisp
Implemented by: Lucid, Inc.
Supported by: Sun
Hardware and operating system: Sun workstation (68xxx-based) with UNIX
Availability: December 1985 (in USA)
Full language or subset: full
Remarks: Calls to functions in other programming languages.
By August 1986 are expected editor, windows, object-oriented programming.
Contact:
???
Name: Apollo Common Lisp
Implemented by: Lucid, Inc.
Supported by: Apollo
Hardware and operating system: Apollo workstation (68xxx-based) with Aegis and DomainIX
Availability: January 1986 (in USA)
Full language or subset: full
Remarks: Calls to functions in other programming languages.
By August 1986 are expected editor, windows, object-oriented programming.
Contact:
???
Name: Prime Common Lisp
Implemented by: Lucid, Inc.
Supported by: Prime
Hardware and operating system: Prime 50 series with Primos (IX mode)
Availability: to be determined
Full language or subset: full
Remarks: Calls to functions in other programming languages.
By August 1986 are expected editor, object-oriented programming.
Contact:
???
Name: Symbolics Cross Compiler for Sun and Apollo
Implemented by: Lucid, Inc.
Supported by: Symbolics, Inc.
Hardware and operating system: Symbolics 3600
Availability: March 1986
Full language or subset: full
Contact:
???
Name: T
Implemented by: Yale University
Supported by: unsupported
Hardware and operating system: Apollo (68000-based), VAX with UNIX, VAX with VMS
Availability: now
Full language or subset: incompatible subset
Missing features: DEFUN, FUNCTION, arrays, sequences, packages, and others
No plans to implement missing features.
Remarks: T is more closely related to SCHEME than to Common Lisp.
Features include tail recursion, single function/variable namespace, lexical environments
used instead of packages, LAMBDA special form, NIL is different from ().
Contact:
Jim Philbin
Yale University
New Haven, Connecticut 06520
USA
Philbin-Jim@Yale.ARPA
∂25-Sep-85 1535 JAR@MIT-MC.ARPA Public relations: data so far
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 15:35:17 PDT
Date: Wed, 25 Sep 85 18:36:54 EDT
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject: Public relations: data so far
To: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Wed 25 Sep 85 17:39 EDT from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MIT-MC.ARPA].659546.850925.JAR>
Lest anyone be confused about the appearance of T in Guy's list of
Common Lisps, I just want to make sure people realize that it was a
joke. I intended it to be a cynical comment on the vacuity of the
concept of "extended subset".
Jonathan
∂25-Sep-85 1844 Moon@SCRC-STONY-BROOK.ARPA Lisp Test
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 18:44:19 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321222; Wed 25-Sep-85 21:39:26-EDT
Date: Wed, 25 Sep 85 21:39 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Lisp Test
To: Tim McNerney <TIM@MIT-MC.ARPA>
cc: GJC@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].658760.850925.TIM>
Message-ID: <850925213949.3.MOON@NEPONSET.SCRC.Symbolics.COM>
Date: Wed, 25 Sep 85 02:59:30 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Date: Sun, 22 Sep 85 21:15:09 EDT
From: George J. Carrette <GJC at MIT-MC.ARPA>
[4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))
...(SETF (FUNCTION ...) ...) does not appear to be
defined in CLtL. Perhaps you meant to use SYMBOL-FUNCTION instead.
Does Common Lisp provide any way to side effect "lexical function cells"
such as G above?
No. They are constants. (More accurately, they take on a new value every
time the FLET is evaluated, but you can't change their value.)
∂25-Sep-85 1845 Moon@SCRC-STONY-BROOK.ARPA Returning additional values from advertised functions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 18:45:46 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321231; Wed 25-Sep-85 21:46:07-EDT
Date: Wed, 25 Sep 85 21:46 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Returning additional values from advertised functions
To: MLY@OZ.MIT
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12144601298.71.MLY@MIT-OZ>
Message-ID: <850925214630.4.MOON@NEPONSET.SCRC.Symbolics.COM>
Date: Thu 19 Sep 85 19:27:24-EDT
From: Richard Mlynarik
I have been inconvenienced several times recently by the fact the
multiple-value-setq is not multiple-value-setf. This is a somewhat
curious shortcoming, especially now that the All-New Fashion in lisp
code seems to be to entirely eschew setq in favour of setf.
(multiple-value-setq (a b c) (foo))
and
(setf (values a b c) (foo))
are identical, and the latter allows you to put the values into other
places besides variables. The latter form is not standard Common Lisp,
but it should be.
∂25-Sep-85 1901 Moon@SCRC-STONY-BROOK.ARPA go and return-from inside unwind-protect cleanup
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 19:00:36 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321241; Wed 25-Sep-85 22:00:55-EDT
Date: Wed, 25 Sep 85 22:01 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <850909130121.2.GLS@IGNATIUS.THINK.COM>
Message-ID: <850925220118.5.MOON@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 9 Sep 85 13:01 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Mon, 9 Sep 85 09:43 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Are the following legal?
(defun foo (go-p)
(prog nil
tag
(unwind-protect
(return (compute))
(if go-p (go tag)))))
(defun bar (return-p)
(prog nil
tag
(unwind-protect
(progn (compute)
(go tag))
(if return-p (return nil)))))
I regard both of these as completely legal.
While they may be legal and implementable, I feel that this programming
style should be strongly discouraged. For one thing, it can be
rather difficult to stop the execution of (FOO T), since any attempt
to THROW out of it will simply cause it to re-enter its infinite loop.
∂25-Sep-85 1914 RAM@C.CS.CMU.EDU Discouraged programming practices
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Sep 85 19:11:31 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 25 Sep 85 22:12:38-EDT
Date: Wed, 25 Sep 1985 22:12 EDT
Message-ID: <RAM.12146204226.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Discouraged programming practices
Another discouraged programming practice is to write
(without-interrupts (loop))
as it may be difficult to terminate the execution of this form.
WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be.
:-)?
Rob
∂26-Sep-85 0100 STEINER@BLUE.RUTGERS.EDU More corrections to CLtL
Received: from BLUE.RUTGERS.EDU by SU-AI.ARPA with TCP; 26 Sep 85 01:00:06 PDT
Date: 26 Sep 85 04:00:01 EDT
From: Dave <Steiner@BLUE.RUTGERS.EDU>
Subject: More corrections to CLtL
To: common-lisp@SU-AI.ARPA
Reply-To: Steiner@Rutgers
I've found several printing bugs in the format chapter.
1) The code on p. 394 to show the scale factor doesn't work. It
should be something like:
(dotimes (k 13)
(format t "~%Scale factor ~2D:~:* |~13,6,2,VE|"
(- k 5) 3.14159))
Ie, Missing % at the beginning and a missing ~:* to back up to the
scale factor again (or add (- k 5) as a third arg in the second
position and don't include the ~:*).
2) The output to this code with scale factor of 7 is missing a 0 after
the decimal point. Ie. |3141590.0E-06|, not | 3141590.E-06|.
3) The format expr in the function definition of FOO (on p 396) is
missing a 4th x arg.
ds
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa: Steiner@RUTGERS
-------
∂26-Sep-85 0404 smh@mit-ems.ARPA CLtL ambiguity in trace
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 04:03:27 PDT
Received: by mit-ems.ARPA (4.12/4.8) id AA12169; Thu, 26 Sep 85 07:03:50 edt
Date: Thu, 26 Sep 85 07:03:50 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509261103.AA12169@mit-ems.ARPA>
To: common-lisp@sail
Subject: CLtL ambiguity in trace
The description on page 440:
trace {function-name}* [Macro]
Invoking trace with one or more function names (symbols)
causes the functions named to be traced. Henceforth,
whenever such a function is invoked ...
It is unclear whether the named function may legally be a macro.
This obviously-useful feature should not cause problems for any
implementation. It should be required, and the manual clarified.
∂26-Sep-85 0432 bs%hp-mars.csnet@CSNET-RELAY.ARPA disassemble and compile questions
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 04:31:55 PDT
Received: from hplabs by csnet-relay.csnet id af16310; 26 Sep 85 7:24 EDT
Received: by HP-VENUS id AA00218; Wed, 25 Sep 85 16:51:09 pdt
Message-Id: <8509252351.AA00218@HP-VENUS>
Date: Wed, 25 Sep 85 16:35:06 pdt
From: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
Received: by HP-MARS id AA24583; Wed, 25 Sep 85 16:35:06 pdt
To: common-lisp@su-ai.arpa
Subject: disassemble and compile questions
Cc: bs@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
I'm in need of enlightenment. The answers to the following two
questions are not obvious from my readings of the book.
1. If f is an interpreted function, does (disassemble 'f)
cause f to become a compiled function?
2. What is the appropriate way to compile a function object
that is not compiled, not a lambda-expression and not the
function definition for a symbol? Consider the "lexical
closure" example in section 2.13 of CLtL.
More on 1:
According to CLtl section 25.1, in the definition of disassemble,
"The argument should be either a function object, a lambda-expression,
or a symbol with a function definition. If the relevent function is
not a compiled function, it is first compiled. ... This is primarily
useful for debugging the compiler ... ."
Side-effecting the function cell by disassembling does not seem like
a result I would desire, especially when debugging the compiler.
Is (compile 'symbol) or (compile nil (symbol-function 'symbol)) the
intended means of compilation?
More on 2:
The definition of compile states that it will only handle lambda-
expressions: "If definition is supplied, it should be a lambda-expression,
the interpreted function to be compiled. If it is not supplied, then
name should be a symbol with a definition that is a lambda-expression;
... ." Section 2.13 states that lists other than lambda expessions
may, in certain implementations, serve as functions. Should the
definition of compile include such cases? I hope so.
Thanks.
∂26-Sep-85 0501 smh@mit-ems.ARPA CLtL error re function special form
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 05:01:04 PDT
Received: by mit-ems.ARPA (4.12/4.8) id AA12317; Thu, 26 Sep 85 08:01:25 edt
Date: Thu, 26 Sep 85 08:01:25 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509261201.AA12317@mit-ems.ARPA>
To: common-lisp@sail
Subject: CLtL error re function special form
Surely this must have been noticed before, but on page 87:
function fn [Special Form]
The value of function is always the functional interpretation
of fn; fn is interpreted as if it had appeared in the
functional-position of a function invocation. In particular,
if fn is a symbol, the functional definition associated with
that symbol is returned; see symbol-function. If fn is a
lambda-expression ...
Unlike the function special form, symbol-function does not see lexical
function bindings. The reference to symbol-function here was probably
intended just to convey the distinction between a symbol's `functional'
interpretation and it's `regular' i.e. symbol-value interpretation.
But it's wrong, and potentially misleading.
Fixing the text is awkward because lexical function binding special
forms are not presented until p.113. But CLtL is more of a reference
than a teaching manual. Perhaps the reference to symbol function
should just be deleted.
A similar but less bothersome slip occurs on p.32 about functional data
types:
A symbol may serve as a function; an attempt to invoke a
symbol as a function causes the contents of the symbol's
function cell to be used. See symbol-function and defun.
∂26-Sep-85 0728 gls@THINK-AQUINAS.ARPA Joke
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 07:27:52 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:29:02 edt
Date: Thu, 26 Sep 85 10:29 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Joke
To: JAR@MIT-MC.ARPA
Cc: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].659523.850925.JAR>
Message-Id: <850926102903.1.GLS@DESIDERIUS.THINK.COM>
Date: Wed, 25 Sep 85 18:14:16 EDT
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
It was a joke, Guy.
Sure fooled me. I figured you just wanted people to know about T as
well as various Common Lisps. If you were willing to send the data, I
was willing to include it.
∂26-Sep-85 0744 AS%hp-hulk.csnet@CSNET-RELAY.ARPA Re: missing function: typep-type-p
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 07:44:50 PDT
Received: from hplabs by csnet-relay.csnet id ab17614; 26 Sep 85 10:41 EDT
Received: by HP-VENUS id AA26541; Thu, 26 Sep 85 07:16:13 pdt
Message-Id: <8509261416.AA26541@HP-VENUS>
Date: Thu 26 Sep 85 07:16:07-PDT
From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Subject: Re: missing function: typep-type-p
To: smh
Cc: common-lisp@su-ai.arpa
In-Reply-To: Message from "Steven Haflich <smh@MIT-EMS@HP-VENUS>" of Thu 26 Sep 85 01:38:35-PDT
Source-Info: From (or Sender) name not authenticated.
I agree with the desirability of a predicate for testing legal
type specifiers. I would call it TYPE-SPECIFIER-P, however.
One might also wish to find out more information about a type
specifier, such as whether it is a structure type or not and,
if so, what type, if any, it is a subtype of.
-------
∂26-Sep-85 0748 gls@THINK-AQUINAS.ARPA go and return-from inside unwind-protect cleanup
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 07:47:29 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:48:38 edt
Date: Thu, 26 Sep 85 10:48 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: Moon@SCRC-STONY-BROOK.ARPA, gls@THINK-AQUINAS.ARPA
Cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <850925220118.5.MOON@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <850926104847.3.GLS@DESIDERIUS.THINK.COM>
Date: Wed, 25 Sep 85 22:01 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Mon, 9 Sep 85 13:01 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Mon, 9 Sep 85 09:43 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Are the following legal?
(defun foo (go-p)
(prog nil
tag
(unwind-protect
(return (compute))
(if go-p (go tag)))))
(defun bar (return-p)
(prog nil
tag
(unwind-protect
(progn (compute)
(go tag))
(if return-p (return nil)))))
I regard both of these as completely legal.
While they may be legal and implementable, I feel that this programming
style should be strongly discouraged. For one thing, it can be
rather difficult to stop the execution of (FOO T), since any attempt
to THROW out of it will simply cause it to re-enter its infinite loop.
I agree that GO should not be used capriciously, especially in company
with UNWIND-PROTECT. (For some *really* awful code of this type, see
the early SCHEME papers.)
I do think that the interaction between GO/RETURN and UNWIND-PROTECT
should be well-defined, however, because of the following kind
of situation:
(DEFMACRO HAIRY-PROTECTED-MACRO-WITH-BODY (...)
`(UNWIND-PROTECT (PROGN ... ,@BODY)
...))
(TAGBODY
...
(HAIRY-PROTECTED-MACRO-WITH-BODY
...
(WHEN (GROSS-ME-OUT) (GO LOSE))
...)
...
LOSE (ERROR "I am grossed out."))
The GO ought to work more-or-less as expected; you shouldn't have to
know that the macro has an UNWIND-PROTECT in it. On the other hand, the
UNWIND-PROTECT must do its job of protecting things, and shouldn't have
to know anything special about a GO being in its body.
--Guy
∂26-Sep-85 0751 gls@THINK-AQUINAS.ARPA Discouraged programming practices
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 07:50:19 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:51:21 edt
Date: Thu, 26 Sep 85 10:51 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Discouraged programming practices
To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <RAM.12146204226.BABYL@C.CS.CMU.EDU>
Message-Id: <850926105132.4.GLS@DESIDERIUS.THINK.COM>
Date: Wed, 25 Sep 1985 22:12 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Another discouraged programming practice is to write
(without-interrupts (loop))
as it may be difficult to terminate the execution of this form.
WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be.
:-)?
Rob
Maybe we should regard it as a valid compiler optimization to compile
this idiom as an exit to the operating system with a message such as
"I'm bored. This program will never terminate, so let's do something else."
This could give greater credence to the joke about a supercomputer
so fast it executes an infinite loop in two seconds.
:-? !
--Guy
∂26-Sep-85 0758 gls@THINK-AQUINAS.ARPA More corrections to CLtL
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 07:58:04 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:58:56 edt
Date: Thu, 26 Sep 85 10:59 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: More corrections to CLtL
To: Steiner@RUTGERS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 26 Sep 85 04:00-EDT from Dave <Steiner@BLUE.RUTGERS.EDU>
Message-Id: <850926105901.5.GLS@DESIDERIUS.THINK.COM>
Date: 26 Sep 85 04:00:01 EDT
From: Dave <Steiner@BLUE.RUTGERS.EDU>
I've found several printing bugs in the format chapter.
1) The code on p. 394 to show the scale factor doesn't work. It
should be something like:
(dotimes (k 13)
(format t "~%Scale factor ~2D:~:* |~13,6,2,VE|"
(- k 5) 3.14159))
Ie, Missing % at the beginning and a missing ~:* to back up to the
scale factor again (or add (- k 5) as a third arg in the second
position and don't include the ~:*).
You are quite right.
2) The output to this code with scale factor of 7 is missing a 0 after
the decimal point. Ie. |3141590.0E-06|, not | 3141590.E-06|.
I disagree. In this case k=7 and d=6. Page 392 specifies that there will
be k (7) digits before the decimal point and d-k+1 (0) digits after the
decimal point. The requirement on page 393, that a zero digit should
appear after the decimal point if permitted by the width constraint,
applies only in the case that the parameter d is omitted.
3) The format expr in the function definition of FOO (on p 396) is
missing a 4th x arg.
Right.
ds
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa: Steiner@RUTGERS
-------
Thanks for the corrections. Keep those cards and letters coming!
--Guy
∂26-Sep-85 0806 gls@THINK-AQUINAS.ARPA CLtL error re function special form
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 08:05:45 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 11:06:48 edt
Date: Thu, 26 Sep 85 11:06 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: CLtL error re function special form
To: smh@MIT-EMS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8509261201.AA12317@mit-ems.ARPA>
Message-Id: <850926110656.6.GLS@DESIDERIUS.THINK.COM>
Date: Thu, 26 Sep 85 08:01:25 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Surely this must have been noticed before, but on page 87:
function fn [Special Form]
The value of function is always the functional interpretation
of fn; fn is interpreted as if it had appeared in the
functional-position of a function invocation. In particular,
if fn is a symbol, the functional definition associated with
that symbol is returned; see symbol-function. If fn is a
lambda-expression ...
Unlike the function special form, symbol-function does not see lexical
function bindings. The reference to symbol-function here was probably
intended just to convey the distinction between a symbol's `functional'
interpretation and it's `regular' i.e. symbol-value interpretation.
But it's wrong, and potentially misleading.
Fixing the text is awkward because lexical function binding special
forms are not presented until p.113. But CLtL is more of a reference
than a teaching manual. Perhaps the reference to symbol function
should just be deleted.
You're right. The text as it stands is misleading. Thanks for catching it.
A similar but less bothersome slip occurs on p.32 about functional data
types:
A symbol may serve as a function; an attempt to invoke a
symbol as a function causes the contents of the symbol's
function cell to be used. See symbol-function and defun.
I don't regard this one as a slip. In a case such as
(cons a b)
the symbol CONS is not being invoked as a function; rather, it is evaluated
in a functional context to yield a function object, and it is that object
that is invoked. In a situation such as
(apply 'cons args)
then the symbol CONS is invoked as a function (APPLY actually sees the
symbol and must dereference it by fetching the function cell); in the context
(apply #'cons args)
it is not (APPLY never sees the symbol, only the function object).
Some examples of this may be needed.
--Guy
∂26-Sep-85 0954 gls@THINK-AQUINAS.ARPA Infinite optimization
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 09:54:22 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 12:55:14 edt
Date: Thu, 26 Sep 85 12:55 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Infinite optimization
To: Rem@IMSSS, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 26 Sep 85 11:59-EDT from Rem at IMSSS
Message-Id: <850926125521.9.GLS@DESIDERIUS.THINK.COM>
Date: 26 Sep 1985 0859-PDT
From: Rem@IMSSS
I like your idea. If an optimizing compiler happens to discover that the
code it's trying to optimize absolutely cannot ever return nor produce any
output, it would be nice for the LUSER if the compiler would inform the
LUSER of that fact instead of blindly compiling a hung CPU and blindly leading
the LUSER into executing it and having to reboot the system to escape it.
Of course if the compiler doesn't happen to discover it, caveat emptor.
Note such a very-smart compiler would wreak havoc with some timing benchmarks
that do nothing useful over and over and throw away all the results; a good
compiler could totally optimize-away such moot calculations, making the
LISP system seem a million times faster than microcode when in fact it
is simply punting the moot calculations. I have long advocated benchmarks
being careful to do truly non-moot calculations. The CRAY-2 test whereby
a large Mersenne prime is verified is a good benchmark. There's no way
an optimizing compiler can turn the benchmark into a punt-cheat, providin
it's a new Mersenne prime nobody computed before and hence couldn't be
included as a special-case optimization a priori. (Did you see/hear the
news story about that CRAY-2 test earlier this week?)
-------
A few years ago a vendor did advertise a set of FORTRAN benchmarks
comparing their machine to a VAX. Most of the numbers were reasonable,
but on one benchmark Brand X was several orders of magnitude faster than
the VAX. This appeared in the table without comment. The fact was that
their compiler had noticed that the results of the inner loops were
unused, and optimized away an entire timing subroutine.
--Guy
∂26-Sep-85 1250 DDYER@SCRC-QUABBIN.ARPA Infinite optimization
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 12:50:08 PDT
Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 205393; Thu 26-Sep-85 15:49:37-EDT
Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 140473; Thu 26-Sep-85 12:55:33-PDT
Date: Thu, 26 Sep 85 12:51 PDT
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: Infinite optimization
To: common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <850926125521.9.GLS@DESIDERIUS.THINK.COM>
Supersedes: <850926124913.8.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <850926125125.9.DDYER@PURPLE.SWW.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Thu, 26 Sep 85 12:55 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: 26 Sep 1985 0859-PDT
From: Rem@IMSSS
I like your idea. If an optimizing compiler happens to discover that the
code it's trying to optimize absolutely cannot ever return nor produce any
output, it would be nice for the LUSER if the compiler would inform the
LUSER of that fact instead of blindly compiling a hung CPU and blindly leading
the LUSER into executing it and having to reboot the system to escape it.
Of course if the compiler doesn't happen to discover it, caveat emptor.
I don't think this is a very likely case. Any loop that calls a
function, or which can be interrupted, can exit via *THROW.
∂26-Sep-85 1455 Moon@SCRC-STONY-BROOK.ARPA go and return-from inside unwind-protect cleanup
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 14:54:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 322135; Thu 26-Sep-85 17:55:12-EDT
Date: Thu, 26 Sep 85 17:55 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <850926104847.3.GLS@DESIDERIUS.THINK.COM>
Message-ID: <850926175528.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have no objection, stylistic or otherwise, to GO inside the
first subform of UNWIND-PROTECT. It's only GO inside of the
cleanup subforms (the second, third, ...) of UNWIND-PROTECT
that makes me barf. The same applies to RETURN, RETURN-FROM,
THROW, and any other transfer-of-control device.
∂26-Sep-85 1516 Moon@SCRC-STONY-BROOK.ARPA disassemble and compile questions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 15:16:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 322160; Thu 26-Sep-85 18:16:10-EDT
Date: Thu, 26 Sep 85 18:16 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: disassemble and compile questions
To: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8509252351.AA00218@HP-VENUS>
Message-ID: <850926181620.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 25 Sep 85 16:35:06 pdt
From: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
I'm in need of enlightenment. The answers to the following two
questions are not obvious from my readings of the book.
I think you've come up with some good places where the book would
benefit from more precise language.
1. If f is an interpreted function, does (disassemble 'f)
cause f to become a compiled function?
That seems like a bad idea (as you say below).
2. What is the appropriate way to compile a function object
that is not compiled, not a lambda-expression and not the
function definition for a symbol? Consider the "lexical
closure" example in section 2.13 of CLtL.
The only kind of uncompiled function object that exists is the lambda
expression.
More on 1:
According to CLtl section 25.1, in the definition of disassemble,
"The argument should be either a function object, a lambda-expression,
or a symbol with a function definition. If the relevent function is
not a compiled function, it is first compiled. ... This is primarily
useful for debugging the compiler ... ."
Side-effecting the function cell by disassembling does not seem like
a result I would desire, especially when debugging the compiler.
Is (compile 'symbol) or (compile nil (symbol-function 'symbol)) the
intended means of compilation?
In Symbolics' implementation, disassemble will compile a lambda
expression, but if given a symbol whose function definition is
interpreted, it will complain rather than compile it. This seems
consistent with the statement that the feature of disassemble compiling
interpreted things is for debugging the compiler.
More on 2:
The definition of compile states that it will only handle lambda-
expressions: "If definition is supplied, it should be a lambda-expression,
the interpreted function to be compiled. If it is not supplied, then
name should be a symbol with a definition that is a lambda-expression;
... ." Section 2.13 states that lists other than lambda expessions
may, in certain implementations, serve as functions. Should the
definition of compile include such cases? I hope so.
I don't think the language designers intended that you be able to compile
lexical closures. Note that it is possible to create two lexical closures
that have a binding in common; in order to compile one of these, leave the
other interpreted, and obtain correct semantics, the compiler would have
to use the same representation of lexical variable binding environments
as the interpreter. Also note that the argument to COMPILE is specified
as a lambda-expression, not as a function in the general sense of section 2.13.
∂27-Sep-85 1512 FAHLMAN@C.CS.CMU.EDU Argument Type Mismatch Errors
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Sep 85 15:12:06 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 27 Sep 85 18:12:35-EDT
Date: Fri, 27 Sep 1985 18:12 EDT
Message-ID: <FAHLMAN.12146684821.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Steven Haflich <smh@MIT-EMS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Argument Type Mismatch Errors
In-reply-to: Msg of 25 Sep 1985 14:31-EDT from Steven Haflich <smh at mit-ems.ARPA>
Unofficially: An implementation obviously should detect and signal
errors when convenient. The primary force against always doing so is
run-time efficiency. Personally, I feel that once an implementation
detects an error such as an inappropriate argument type, it should
always signal the error rather than silently proceeding. There's no
reason not to signal the error, assuming the price of detecting it has
already been paid.
I disagree with this slightly. In some cases the book says "is an
error" rather than "signals an error" because we recognized that on some
machines it might be costly to detect and signal certain errors. But in
other cases, the motivation was to allow flexibility for experimenting
with non-standard language extensions. So I can certainly imagine some
situations in which an implementation detects an error but deliberately
goes on to do something other than signalling the error. The existence
of such extensions should not be taken as a license for sloppy
implementation, however: extensions of this sort should be carefully
considered and should be well-documented.
-- Scott
∂30-Sep-85 1724 bs%hp-mars.csnet@CSNET-RELAY.ARPA Re: disassemble and compile questions
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 17:23:52 PDT
Received: from hplabs by csnet-relay.csnet id bb17699; 30 Sep 85 20:17 EDT
Received: by HP-VENUS id AA12153; Mon, 30 Sep 85 11:29:45 pdt
Message-Id: <8509301829.AA12153@HP-VENUS>
Date: Mon, 30 Sep 85 11:28:47 pdt
From: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
Received: by HP-MARS id AA23741; Mon, 30 Sep 85 11:28:47 pdt
To: common-lisp <@CSNET-RELAY.ARPA,@hplabs.CSNET:common-lisp@su-ai.arpa>
Subject: Re: disassemble and compile questions
Cc: bs@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
Well, I essentially shot myself in the foot with the wording of my
question about compiling things other than lambda-expressions.
Lexical closures were a convenient example, not the real concern.
Let me make another attempt.
Is it allowable to have a function object that is specified by
a lambda-expression but is not stored as a lambda-expression or
compiled code? In other words, does Common Lisp allow intermediate,
iterpretable representations? If it is possible to have such a
function object, is there a mechanism by which it can be later compiled?
In section 5.3.1 it states, "Evaluating a defun form causes the symbol
name to be a global name for the function specified by the lambda-
expression ... ." This doesn't seem to preclude an intermediate form.
In section 2.13 it states, "A function is anything that may be correctly
given to the funcall or apply function, and is to be executed as code
when arguments are supplied." Funcall is defined in terms of functions
(section 7.3) and apply (section 7.3) states, "function may be a
compiled-code object, or a lambda-expression, or a symbol ... ." If
I interpret "may" as "must" in the preceding statement, then, for
such an intermediate form, (apply 'f 1 2 3) is legal, but
(apply (symbol-function 'f) 1 2 3) is not.
Thanks for any help.
∂30-Sep-85 1734 FAHLMAN@C.CS.CMU.EDU disassemble and compile questions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Sep 85 17:33:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 30 Sep 85 20:34:52-EDT
Date: Mon, 30 Sep 1985 20:34 EDT
Message-ID: <FAHLMAN.12147497155.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: disassemble and compile questions
The language spec says nothing about what a compiled-code object looks
like, so it seems perfectly reasonable to me that an implementation
could have several internal compiled code formats, some (a lot) more
compiled than others. Also, many implementations do a little work on
the lambda expression that would otherwise be produced by DEFUN before
storing it in a function cell, at least to the extent of making that
implicit BLOCK explicit.
-- Scott
∂30-Sep-85 1948 GJC@MIT-MC.ARPA go and return-from inside unwind-protect cleanup
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 19:48:16 PDT
Date: Mon, 30 Sep 85 22:50:57 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: Moon@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM,
DCP@SCRC-QUABBIN.ARPA
In-reply-to: Msg of Wed 25 Sep 85 22:01 EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MIT-MC.ARPA].664177.850930.GJC>
About a year ago I gave (prog nil foo (unwind-protect (compute) (go
foo)) as a challange to folks at LMI. Pace Willison was able to get
out by using the single-step macro-instruction mode he had just
implemented in the debugger, to execute the CONTROL-R command right
before to (GO FOO) instruction. I was suprised he was able to get
out because he hadn't told me about the new debugger command.
The awful construct came up during the translation of some code in C
that used SETJMP/SIGNAL/LOGJMP into lisp.
∂01-Oct-85 1022 gray@GSWD-VMS UNIX terminal io incompatibility
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 10:21:49 PDT
Date: Tue, 01 Oct 85 12:21:30 CDT
From: gray@GSWD-VMS
Subject: UNIX terminal io incompatibility
To: common-lisp@su-ai.arpa
Cc: gray
Common Lisp maps poorly onto UNIX(tm) in the area of terminal io.
On pages 328 and 329 of CLtL it says:
"*standard-input*, *standard-output*, *error-output*, *trace-
output*, *query-io*, and *debug-io* are initially bound to
synonym streams that pass all operations on to the stream that is
the value of *terminal-io*." Earlier on, the specification
describes *query-io* and *debug-io* as always being interactive
streams.
These requirements cause problems under UNIX when you redirect
the output of a program, specifically when you redirect the
output of a Lisp session. For example:
clisp > FOO
If we follow the specification and attach *terminal-io* to UNIX
stdin/stdout file descriptors and leave all the other streams
bound to *terminal-io*, output from *debug-io* will also be
redirected to the file, not to the terminal. If we attach
*terminal-io* to /dev/tty and leave the other streams bound to
*terminal-out*, then UNIX redirection doesn't work.
Our proposed solution is to attach *terminal-io* to /dev/tty,
then attach *standard-in* to UNIX stdin and *standard-out* to
UNIX stdout (not to *terminal-io*). All the other io streams
remain bound to *terminal-io*.
This permits the user to redirect stdin and stdout, and output
from *debug-io*, etc., still appears on the terminal. Although
this does not abide by the standard, it is useful enough that we
propose it as a UNIX-specific addition.
Anne Jane Gray
Gould CSD, Urbana, IL.
∂01-Oct-85 1106 ANDY@SU-SUSHI.ARPA Re: UNIX terminal io incompatibility
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 11:05:50 PDT
Date: Tue 1 Oct 85 10:57:17-PDT
From: Andy Freeman <ANDY@SU-SUSHI.ARPA>
Subject: Re: UNIX terminal io incompatibility
To: gray@GSWD-VMS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "gray@GSWD-VMS" of Tue 1 Oct 85 10:37:56-PDT
Unix isn't the only operating system with redirectable output.
(TOPS-20, believe it or not, does also; probably Tenex does as well.
.priin and .priou are similar to stdin and stdout. The reason you've
never heard of it is that they couldn't figure out a decent exec
syntax.)
If one is going to attach *standard-output* and *standard-input* to
stdout and stdin respectively, *error-output* should be attached to
stderr. I don't know about *trace-output*.
-andy
-------
∂01-Oct-85 1148 DLW@SCRC-STONY-BROOK.ARPA Re: disassemble and compile questions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 11:47:36 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 324445; Tue 1-Oct-85 14:41:44-EDT
Date: Tue, 1 Oct 85 14:40 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: disassemble and compile questions
To: bs%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
cc: bs@hplabs.CSNET
In-Reply-To: <8509301829.AA12153@HP-VENUS>
Message-ID: <851001144005.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Mon, 30 Sep 85 11:28:47 pdt
From: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
Is it allowable to have a function object that is specified by
a lambda-expression but is not stored as a lambda-expression or
compiled code? In other words, does Common Lisp allow intermediate,
iterpretable representations? If it is possible to have such a
function object, is there a mechanism by which it can be later compiled?
In my opinion, this is the correct answer: Any Common Lisp
implementation is allowed to have its own, non-standard (not in CLtL),
additional kinds of functions. Programs written in such a way as to
make this additional thing visible might not end up being portable. So
in your case, the answer is yes, it's OK for you to put in your own
additional (intermediate, or whatever) representation, but programs that
want to be portable will have to not depend on its existence.
If I interpret "may" as "must" in the preceding statement, then, for
such an intermediate form, (apply 'f 1 2 3) is legal, but
(apply (symbol-function 'f) 1 2 3) is not.
I don't understand how you conclude this. The latter form is also legal.
After all, it is defined that what happens when you apply a symbol is
that the object in the symbol's function cell is applied instead (see
2.13 again).
∂01-Oct-85 1545 GJC@MIT-MC.ARPA UNIX terminal io incompatibility
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 15:45:44 PDT
Date: Tue, 1 Oct 85 18:48:29 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject: UNIX terminal io incompatibility
To: ANDY@SU-SUSHI.ARPA
cc: common-lisp@SU-AI.ARPA, gray@GSWD-VMS.ARPA
In-reply-to: Msg of Tue 1 Oct 85 10:57:17-PDT from Andy Freeman <ANDY at SU-SUSHI.ARPA>
Message-ID: <[MIT-MC.ARPA].665347.851001.GJC>
VMS also has redirectable input/output.
$ define/user sys$output ...
$ define/user sys$input ...
$ define/user sys$error ...
$ define/user sys$command ...
one might wonder what DEC COMMON LISP does in this case.
∂01-Oct-85 2333 STEINER@RED.RUTGERS.EDU Another printing bug in CLtL
Received: from RED.RUTGERS.EDU by SU-AI.ARPA with TCP; 1 Oct 85 23:33:14 PDT
Date: 2 Oct 85 02:33:00 EDT
From: Dave <Steiner@RED.RUTGERS.EDU>
Subject: Another printing bug in CLtL
To: common-lisp@SU-AI.ARPA
On p. 396 in the examples of using ~G for format, one of the examples
is:
(foo 3.14E12) => "*********|314.2$+10|0.314E+13| 3.14L+12"
↑ ↑
| |
| shouldn't this be E?
|
shouldn't this be a 0?
ds
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa: Steiner@RUTGERS
-------
∂02-Oct-85 0808 gls@THINK-AQUINAS.ARPA Another printing bug in CLtL
Received: from THINK.COM by SU-AI.ARPA with TCP; 2 Oct 85 08:08:40 PDT
Received: from yon by GODOT.THINK.COM via CHAOS; Wed, 2 Oct 85 11:09:52 edt
Date: Wed, 2 Oct 85 11:09 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Another printing bug in CLtL
To: Steiner@RED.RUTGERS.EDU, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 2 Oct 85 02:33-EDT from Dave <Steiner@RED.RUTGERS.EDU>
Message-Id: <851002110940.1.GLS@YON.THINK.COM>
Date: 2 Oct 85 02:33:00 EDT
From: Dave <Steiner@RED.RUTGERS.EDU>
On p. 396 in the examples of using ~G for format, one of the examples
is:
(foo 3.14E12) => "*********|314.2$+10|0.314E+13| 3.14L+12"
↑ ↑
| |
| shouldn't this be E?
|
shouldn't this be a 0?
ds
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa: Steiner@RUTGERS
-------
Right you are. Thank you very much.
--Guy
∂02-Oct-85 1505 mips!escargot.earl@glacier Another printing bug in CLtL
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 15:04:26 PDT
Received: by glacier with Sendmail; Wed, 2 Oct 85 15:03:59 pdt
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
id AA03750; Wed, 2 Oct 85 14:35:10 pdt
Received: by escargot.UUCP (4.12/4.7)
id AA00772; Wed, 2 Oct 85 14:33:32 pdt
Date: Wed, 2 Oct 85 14:33:32 pdt
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8510022133.AA00772@escargot.UUCP>
To: gls@THINK-AQUINAS.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: Guy Steele's message of Wed, 2 Oct 85 11:09 EDT
Subject: Another printing bug in CLtL
Now that a few common lisp implementations exist, maybe someone should
take all the examples in the book and execute them. This wasn't possible
when the book was written, but it is now...
∂02-Oct-85 1800 @MIT-MC.ARPA:uucp@MIT-CCC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 18:00:29 PDT
Received: from MIT-CCC by MIT-MC.ARPA via Chaosnet; 2 OCT 85 20:15:04 EDT
Date: 2 Oct 1985 19:47:40-EDT
From: uucp@MIT-CCC
From gjc@cap Wed Oct 2 15:05:08 1985 remote from LMI-CAPRICORN
Received: from LMI-LAMBDA-6 by LMI-LAMBDA-3 with CHAOS-MAIL; Wed 2-Oct-1985 15:03:28-EDT
Date: Wednesday, 2 October 1985, 15:03-EDT
From: George Carrette <gjc@cap>
Subject: lisp listings
To: mitccc!common-lisp%su-ai%mc@cap
I'll send this directly to the whole mailing list to give
people a chance to point out anything I've left out.
Here are two listings:
(1) MIT-LISPMACHINE SYSTEM, or MIT-ZETALISP, MIT-SYSTEM 99
(2) implemented at MIT AI LAB
(3) MIT-CADR, LMI-CADR, SYMBOLICS-LM2
(4) now
(5) full
(6) in fact a couple numerical functions such as complex ACOS seem to be missing.
(7) no commercial support.
(8) Systemic: Flavors, ZMACS editor, chaosnet protocols on chaos or ethernet hardware.
File-System.
Applications: check through the AI LAB memos.
(1) ZETALISP-PLUS(tm)
(2) Lisp Machine Inc.
(3) LMI-LAMBDA(tm), LMI-LAMBDA-E(tm), TI-EXPLORER(tm).
(4) now.
(5) full.
(7) Lisp Machine Inc
6 Tech Drive
Andover MA 01810
671-689-3554, or 1-800-USA-LISP for customer service.
(8) Systemic: Flavors, ZMACS editor, chaosnet and tcp-ip protocols on ethernet hardware.
File-System. ObjectLisp(tm) alternative object oriented programming system.
Applications:
PICON(tm) Industrial Process Control System.
DOE-MACSYMA, symbolic algebra system.
VISTA(tm) 3-D generic graphics system and window-system extensions
implemented in ObjectLisp(tm).
KEE(tm), ART(tm).
The applications are of course mainly in the Zetalisp we all know and
loved, so even though one could come up with an impressively long list
of lispmachine software applications that could be misleading, in that
that not all those applications were in fact in "Common-Lisp." The
ObjectLisp(tm) package is the closest (Objectlisp(tm) uses LOOP at this time)
to being common lisp, running on the Symbolics, LMI, and MIT VAX-NIL
implementations.
∂03-Oct-85 1436 DCP@SCRC-QUABBIN.ARPA Arguments and values to get.
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 14:36:29 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 207346; Thu 3-Oct-85 17:40:11-EDT
Date: Thu, 3 Oct 85 17:39 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Arguments and values to get.
To: Gregor.pa@XEROX.ARPA, Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, Common-Lisp@SU-AI.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <850919-174345-1059@Xerox>,
<FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>,
<850920100928.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <851003173940.1.DCP@NEPONSET.SCRC.Symbolics.COM>
Consider
(incf (get foo bar))
when the property does not exist. INCF would die adding to NIL. Thus,
to maintain simple style, you need
(incf (get foo bar 0))
I think this is a LOT prettier than
(setf (get foo bar)
(multiple-value-bind (value valid-p)
(get foo bar)
(if valid-p (1+ value) 1)))
and the programmer doesn't have to worry about multiple evaluation of
FOO and BAR, since INCF is supposed to take care of that.
∂03-Oct-85 1451 DCP@SCRC-QUABBIN.ARPA Discouraged programming practices
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 14:50:55 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 207354; Thu 3-Oct-85 17:54:34-EDT
Date: Thu, 3 Oct 85 17:54 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Discouraged programming practices
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12146204226.BABYL@C.CS.CMU.EDU>
Message-ID: <851003175412.2.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Wed, 25 Sep 1985 22:12 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Another discouraged programming practice is to write
(without-interrupts (loop))
as it may be difficult to terminate the execution of this form.
WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be.
:-)?
On the serious side, what exactly does WITHOUT-INTERRUPTS mean? Does it
mean WITHOUT-SCHEDULING, as it does on a variety of Lisp Machines? Does
it mean WITHOUT-SCHEDULING-AND-WITHOUT-IO-DEVICES, which is what it
could mean on a 68000, PDP-11 or variety of other machines. Does it
mean WITHOUT-OPERATING-SYSTEM (which on a time sharing system would be
very anti-social). On a multi-processor (tightly coupled, loosely
coupled, or in between doesn't matter), does it mean some of the above
for the processor executing it, or does it mean
WITHOUT-ANY-OTHER-PROCESSOR. Does spawning of sub-tasks to other
processors inherit the WITHOUT-INTERRUPTS.
In other words, WITHOUT-INTERRUPTS is much to vague to put in Common
Lisp.
∂03-Oct-85 1507 wagner@GSWD-VMS CLtL binding
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 15:04:08 PDT
Date: Thu, 03 Oct 85 17:03:50 CDT
From: wagner@GSWD-VMS
Subject: CLtL binding
To: common-lisp@su-ai.arpa
Cc: wagner
Concerning binding...no, not of variables, of the book!
My copy of CLtL is falling apart after a few months of
hard use because of the "perfect" binding. I'd pay a
few extra dollars for sewn signatures in the next edition.
Fran Wagner
Gould CSD-Urbana
∂03-Oct-85 1910 RAM@C.CS.CMU.EDU Without-Interrupts
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Oct 85 19:07:46 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Oct 85 22:08:40-EDT
Date: Thu, 3 Oct 1985 22:08 EDT
Message-ID: <RAM.12148300645.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Without-Interrupts
In-reply-to: Msg of 3 Oct 1985 17:54-EDT from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
It is true that WITHOUT-INTERRUPTS could mean a number of things,
but that doesn't mean that it has no place in portable code. The
primary use is in protecting code which modifies data structures so
that the update appears atomic as far as the user is concerned. No
matter where he types ↑G, the data structures of his program won't get
trashed. Although Common Lisp doesn't require asynchronous interrupts
from the user, any reasonable implementation will have them, and good
software must deal with that fact somehow.
Note that Common Lisp only defines a single-thread environment,
thus the behavior of WITHOUT-INTERRUPTS in a multiple-thread Lisp
implementation wouldn't be a proper part of its Common Lisp
specification. In a multi-thread environment, it should probably freeze
out all other threads during the execution of the body. This makes it
very expensive in a multiprocessor, and therefore probably useless,
but then nobody ever said that writing software for a multiprocessor
was easy.
I believe that the Lisp machine interpretation is about right,
although it is silly to talk about "inhibiting scheduling" in a
single-thread implementation. WITHOUT-INTERRUPTS shouldn't have
anything to do with real hardware interrupts, it affects "software
interrupts". Although some systems might get upset if you ran without
interrupts for minutes, programmers who use WITHOUT-INTERRUPTS
in a "reasonable" fashion shouldn't have to worry about trashing the
system.
WITHOUT-INTERRUPTS should nest properly, which means that
(without-interrupts xxx)
can't turn into
(interrupts-off) xxx (interrupts-on)
Spice Lisp (and Zetalisp, I believe), implement WITHOUT-INTERRUPTS by
binding a special variable which the low-level interrupt handling
mechanism looks at before deciding to actually service an interrupt.
Rob
∂04-Oct-85 1548 DLW@SCRC-STONY-BROOK.ARPA implicit blocks
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Oct 85 15:48:34 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 327115; Fri 4-Oct-85 18:49:36-EDT
Date: Fri, 4 Oct 85 18:48 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: implicit blocks
To: common-lisp@SU-AI.ARPA
cc: BSG@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA,
Margulies@SCRC-YUKON.ARPA, mbell@SCRC-YUKON.ARPA,
bug-compiler@SCRC-YUKON.ARPA
Message-ID: <851004184805.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
From our reading of the manual, it appears that while functions defined
by DEFUN have an implicit BLOCK around them, functions defined by FLET
and LABELS do not. Several people here have been discussing this, and
the concensus seems to be that FLET and LABELS functions really ought to
set up such a block implicitly, both for uniformity with DEFUN and for
the same reasons that DEFUN does so in the first place.
I don't recall ever hearing this issue discussed. I don't think that
omitting the implicit BLOCK from FLET and LABELS was intentional. If
I'm wrong about these points, please let me know. If we develop a
procedure for making small language definition changes, I think this one
ought to be made. Fortunately, it seems highly unlikely that the change
would break any existing programs.
∂07-Oct-85 1054 RPG
To: common-lisp@SU-AI.ARPA, Squires@USC-ISI.ARPA,
Ohlander@USC-ISI.ARPA
Common Lisp Meeting
Here is a summary of the responses I got to the suggestion of a
Common Lisp meeting and some suggestions I have on its organization:
1. The meeting will be held either at MIT or at a local convention
center in the Boston Area.
2. The meeting will last 2 days.
3. The dates are, Thursday and Friday, Decemeber 5 and 6.
4. The schedule of events will be:
Thurs 8:30am Welcome, registration, and coffee
9:00am Charter Discussion
Noon Lunch (brought in)
[Informal discussion and lobbying]
1:00pm Charter Discussion
Fri 8:30am Coffee
9:00am Parallel discussions on:
Object-oriented programming
Errors
Validation
ANSI
Windows
Noon Lunch (brought in)
1:00pm Parallel Discussion
5:00pm Hit the Road
During the Charter discussion, the following topics will be discussed:
Inclusion of the recent minor changes and errata to the
Common Lisp specification
Methods for updating the book (second edition)
Publishing problems - some vendors wish to have a language manual
for their Common Lisp and desire to publish it themselves.
Making decisions during the parallel sessions on Friday
Administrative format of validation
* * *
Suggested Administrative Format of the Charter Discussion
[Please note: these are my suggestions and do not represent an edict.]
At the start of each session, including the Charter session, the chairman
of the committee will review the state of the discussion under his
purview.
Each organization - company or university - doing an implementation of Common
Lisp may send 2 representatives who can comment and vote during the
Charter discussion. Each organization representing a significant user
community may send 1 individual who can comment and vote during the
Charter discussion. Interested individuals of standing in the Lisp
community may also attend and vote; however, some votes may be taken
in which implementors only may vote.
In addition, each organization doing an implementation may send 2 people
to each of the parallel discussions, but only 1 of those may vote. Each
organization representing a significant user community may send 1 person
to each of the parallel discussions. Individuals may attend the parallel
discussions, but they might be restricted from voting in some cases as
in the Charter Discussion.
Each discussion will be run approximately according to Robert's Rules of
Order to keep things under control. I assume only Guy Steele knows these
rules, so perhaps he should help run the Charter discussion so that the
other chairmen will learn how to do it. I know this sounds silly, but
remember the madhouse at Monterey.
I would like to get a list of the proposed attendees for planning
purposes. I would also like to solicit one of our friends for the Boston
Area to arrange for the meeting rooms. Once I have a count of attendees, I
will pass the information on to that person.
I propose that the meeting rooms, morning coffee, and the lunches be
paid for by DARPA.
-rpg-
∂08-Oct-85 0917 OLDMAN@USC-ISI.ARPA UNIX terminal io incompatibility
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 09:17:17 PDT
Date: 8 Oct 1985 12:18-EDT
Sender: OLDMAN@USC-ISI.ARPA
Subject: UNIX terminal io incompatibility
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA] 8-Oct-85 12:18:11.OLDMAN>
Data General Common LISP also has redirectable output.
execute lisp/I=infile/O=outfile/E=errorfile
The presence of any of these switches causes the default bindings of
the standard streams to change. *terminal-io* is still attached to
the console if one is available. If one is not available (such as when
you are running in batch mode), we have a slightly crazy set of rules
that "do the right thing".
-- Dan Oldman
∂09-Oct-85 1018 RPG Response to CL Meeting Announcement
To: common-lisp@SU-AI.ARPA
Friends:
There has been some concern expressed about parallel sessions.
When you respond to me regarding the proposed schedule, please also
indicate your preference for parallel sessions over 2 days versus
sequential sessions over 3 days. Also, would the week after
December 5 - namely, December 9, 10, 11 - be open for you as well?
Some people mentioned a problem with December 5 and 6.
Thank you.
-rpg-
∂10-Oct-85 0528 GJC@MIT-MC.ARPA Response to CL Meeting Announcement
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 05:28:10 PDT
Date: Thu, 10 Oct 85 08:31:06 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject: Response to CL Meeting Announcement
To: RPG@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 09 Oct 85 1018 PDT from Dick Gabriel <RPG at SU-AI.ARPA>
Message-ID: <[MIT-MC.ARPA].674959.851010.GJC>
I think parallel sessions are fine as long as there are not more
than two at once.
∂10-Oct-85 1708 isrlist@tove.umd.edu
Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 10 Oct 85 17:05:23 PDT
∂10-Oct-85 1726 SCHUMACHER%hp-hulk.csnet@CSNET-RELAY.ARPA pathnames.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 17:26:41 PDT
Received: from hplabs by csnet-relay.csnet id ac14781; 10 Oct 85 20:25 EDT
Received: by HP-VENUS id AA02649; Thu, 10 Oct 85 16:06:27 pdt
Message-Id: <8510102306.AA02649@HP-VENUS>
Date: Thu 10 Oct 85 16:06:07-PDT
From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
Subject: pathnames.
To: common-lisp@su-ai.arpa
Cc: freeze@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
The manual doesn't state explicitly that the accessor functions for
pathname objects are setf'able. Is this an oversight on my part, the
manuals part, or is there some justification for this. Admittedly the
desired effect can be achieved using make-pathname with the current
pathname as the :default and the desired change specified as a keyword
arg, but this seems sort of strange ...
Lee Schumacher
-------
∂10-Oct-85 1739 DCP@SCRC-STONY-BROOK.ARPA pathnames.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 17:39:20 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 331605; Thu 10-Oct-85 20:42:16-EDT
Date: Thu, 10 Oct 85 20:42 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: pathnames.
To: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
cc: freeze@hplabs.CSNET
In-Reply-To: <8510102306.AA02649@HP-VENUS>
Message-ID: <851010204203.2.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Thu 10 Oct 85 16:06:07-PDT
From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
The manual doesn't state explicitly that the accessor functions for
pathname objects are setf'able. Is this an oversight on my part, the
manuals part, or is there some justification for this. Admittedly the
desired effect can be achieved using make-pathname with the current
pathname as the :default and the desired change specified as a keyword
arg, but this seems sort of strange ...
Symbolics interns our pathnames. Is SYMBOL-NAME setf'able?
∂11-Oct-85 0748 wagner@GSWD-VMS oversight?
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 07:48:00 PDT
Date: Fri, 11 Oct 85 09:47:43 CDT
From: wagner@GSWD-VMS
Subject: oversight?
To: common-lisp@su-ai.arpa
Cc: wagner
On page 418 of CLtL, concerning the OPEN function: "The filename
...may be a string, a pathname, or a stream." May it not also be
a symbol, and shouldn't the spec say so? Same for WITH-OPEN-FILE,
etc.? (The underlying pathname functions work with symbols.)
Fran Wagner
Gould CSD-Urbana
∂11-Oct-85 1242 Moon@SCRC-STONY-BROOK.ARPA oversight?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 12:42:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 332245; Fri 11-Oct-85 15:32:50-EDT
Date: Fri, 11 Oct 85 15:32 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: oversight?
To: wagner@GSWD-VMS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Oct 85 10:47-EDT from wagner@GSWD-VMS
Message-ID: <851011153205.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 11 Oct 85 09:47:43 CDT
From: wagner@GSWD-VMS
On page 418 of CLtL, concerning the OPEN function: "The filename
...may be a string, a pathname, or a stream." May it not also be
a symbol, and shouldn't the spec say so? Same for WITH-OPEN-FILE,
etc.? (The underlying pathname functions work with symbols.)
It's true that most places in the manual say that symbols are acceptable
where pathnames are required, and are parsed as namestrings. I don't
understand why this feature is in there; it seems like asking for trouble.
What about implementations (yes they exist) where some streams are
implemented as symbols? How do you tell whether a symbol was supposed to
be a stream or supposed to be a string? What if NIL is accidentally used
where a pathname was expected, do you really want to get a file named "NIL"?
It's possible that the feature of allowing symbols as pathnames was blindly
copied from an old version of Zetalisp, which used to allow that. A couple
of bad ideas got into Common Lisp that way, in spite of significant effort
by the committee to try to keep it from happening. Zetalisp allowed symbols
for compatibility with an old version of pdp-10 Maclisp that didn't have
strings.
∂11-Oct-85 1549 hplabs!schumacher%hplabs.csnet@CSNET-RELAY.ARPA Re: pathnames.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 15:49:11 PDT
Received: from hplabs by csnet-relay.csnet id ag23808; 11 Oct 85 18:38 EDT
Received: by HP-VENUS id AA04620; Fri, 11 Oct 85 09:17:59 pdt
Message-Id: <8510111617.AA04620@HP-VENUS>
Date: Friday, October 11, 1985 08:53:50
From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA
Subject: Re: pathnames.
To: hplabs!DCP%scrc-quabbin.arpa@csnet-relay.arpa
Cc: common-lisp@su-ai.arpa
In-Reply-To: Your message of 10-Oct-85 20:42:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info: From (or Sender) name not authenticated.
Date: Thu, 10 Oct 85 20:42 EDT
From: "David C. Plummer" <hplabs!DCP%scrc-quabbin.arpa@CSNET-RELAY>
Date: Thu 10 Oct 85 16:06:07-PDT
From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
The manual doesn't state explicitly that the accessor functions for
pathname objects are setf'able. Is this an oversight on my part, the
manuals part, or is there some justification for this. Admittedly the
desired effect can be achieved using make-pathname with the current
pathname as the :default and the desired change specified as a keyword
arg, but this seems sort of strange ...
Symbolics interns our pathnames. Is SYMBOL-NAME setf'able?
I'm not sure I understand this statement (question?). Are you interning
the namestring of the pathname ? Perhaps I should have been more specific:
given a path name (setq foo (pathname "<dir>foo.bar")) I want to change the
type field of pathname foo to be "jnk". Is it legal cl to say
(setf (pathname-type foo) "jnk") ? If this isn't legal then it seems that
the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)).
Is that any clearer ?
-------
∂11-Oct-85 2025 Moon@SCRC-STONY-BROOK.ARPA Re: pathnames.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 20:25:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 332541; Fri 11-Oct-85 23:28:00-EDT
Date: Fri, 11 Oct 85 23:27 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: pathnames.
To: schumacher%hplabs.csnet@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8510111617.AA04620@HP-VENUS>
Message-ID: <851011232700.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Friday, October 11, 1985 08:53:50
From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA
Date: Thu, 10 Oct 85 20:42 EDT
From: "David C. Plummer" <hplabs!DCP%scrc-quabbin.arpa@CSNET-RELAY>
Date: Thu 10 Oct 85 16:06:07-PDT
From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
The manual doesn't state explicitly that the accessor functions for
pathname objects are setf'able. Is this an oversight on my part, the
manuals part, or is there some justification for this. Admittedly the
desired effect can be achieved using make-pathname with the current
pathname as the :default and the desired change specified as a keyword
arg, but this seems sort of strange ...
Symbolics interns our pathnames. Is SYMBOL-NAME setf'able?
I'm not sure I understand this statement (question?). Are you interning
the namestring of the pathname ? Perhaps I should have been more specific:
given a path name (setq foo (pathname "<dir>foo.bar")) I want to change the
type field of pathname foo to be "jnk". Is it legal cl to say
(setf (pathname-type foo) "jnk") ? If this isn't legal then it seems that
the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)).
Is that any clearer ?
Perhaps I can clarify. In Common Lisp it is not legal to change the components
of a pathname, for the same reasons that it is not legal to change the name of
a symbol and not legal to change the denominator of a ratio.
In Symbolics' implementation, every time you ask for a pathname with the same
components, you get the same object, so that pathname equality can be tested
with EQ. This is what DCP was pointing out. However, this is irrelevant.
Even in a system that didn't "intern" or "canonicalize" pathnames in this way,
it would be inappropriate to perform side-effects on a pathname because it
might be in use by someone else. That's the basis for the language design;
unfortunately it isn't explained in the manual. You're correct that the way
to get a pathname that is like another pathname but with one component different
is to call make-pathname.
∂15-Oct-85 1119 RLB@SCRC-STONY-BROOK.ARPA Re: pathnames.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 11:19:31 PDT
Received: from PETREL.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 334182; Tue 15-Oct-85 14:21:51-EDT
Date: Tue, 15 Oct 85 14:21 EDT
From: Richard L. Bryan <RLB@SCRC-QUABBIN.ARPA>
Subject: Re: pathnames.
To: Moon@SCRC-STONY-BROOK.ARPA, schumacher%hplabs.csnet@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851011232700.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851015142135.3.RLB@PETREL.SCRC.Symbolics.COM>
Date: Fri, 11 Oct 85 23:27 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Friday, October 11, 1985 08:53:50
From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA
Date: Thu, 10 Oct 85 20:42 EDT
From: "David C. Plummer" <hplabs!DCP%scrc-quabbin.arpa@CSNET-RELAY>
Date: Thu 10 Oct 85 16:06:07-PDT
From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
The manual doesn't state explicitly that the accessor functions for
pathname objects are setf'able. Is this an oversight on my part, the
manuals part, or is there some justification for this. Admittedly the
desired effect can be achieved using make-pathname with the current
pathname as the :default and the desired change specified as a keyword
arg, but this seems sort of strange ...
Symbolics interns our pathnames. Is SYMBOL-NAME setf'able?
I'm not sure I understand this statement (question?). Are you interning
the namestring of the pathname ? Perhaps I should have been more specific:
given a path name (setq foo (pathname "<dir>foo.bar")) I want to change the
type field of pathname foo to be "jnk". Is it legal cl to say
(setf (pathname-type foo) "jnk") ? If this isn't legal then it seems that
the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)).
Is that any clearer ?
Perhaps I can clarify. In Common Lisp it is not legal to change the components
of a pathname, for the same reasons that it is not legal to change the name of
a symbol and not legal to change the denominator of a ratio.
In Symbolics' implementation, every time you ask for a pathname with the same
components, you get the same object, so that pathname equality can be tested
with EQ. This is what DCP was pointing out. However, this is irrelevant.
Even in a system that didn't "intern" or "canonicalize" pathnames in this way,
it would be inappropriate to perform side-effects on a pathname because it
might be in use by someone else. That's the basis for the language design;
unfortunately it isn't explained in the manual. You're correct that the way
to get a pathname that is like another pathname but with one component different
is to call make-pathname.
Perhaps SETF of pathname components should work the same
way as SETF of LDB.
∂15-Oct-85 1247 RWK@SCRC-STONY-BROOK.ARPA Re: pathnames.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 12:47:29 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 334265; Tue 15-Oct-85 15:26:34-EDT
Date: Tue, 15 Oct 85 15:25 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Re: pathnames.
To: Richard L. Bryan <RLB@SCRC-QUABBIN.ARPA>
cc: Moon@SCRC-STONY-BROOK.ARPA, schumacher%hplabs.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: <851015142135.3.RLB@PETREL.SCRC.Symbolics.COM>
Message-ID: <851015152519.4.RWK@CROW.SCRC.Symbolics.COM>
Date: Tue, 15 Oct 85 14:21 EDT
From: Richard L. Bryan <RLB@SCRC-QUABBIN.ARPA>
Perhaps SETF of pathname components should work the same
way as SETF of LDB.
As former pathnamemeister for Symbolics (theoretically retired)
I concur with Moon's analysis and RLB's suggestion.
For uniformity we could extend this to other read-only accessors
like SYMBOL-NAME, and DENOMINATOR although it's hard to see it as
useful in the former case, and it's pretty strange in the later
(and probably indicative of a woefully ineffecient program).
∂15-Oct-85 1520 GSB@MIT-MC.ARPA SETF of pathname components
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 15:20:25 PDT
Date: Tue, 15 Oct 85 18:23:24 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: SETF of pathname components
To: RWK@SCRC-YUKON.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].680489.851015.GSB>
Date: Tue, 15 Oct 85 15:25 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
. . .
For uniformity we could extend this to other read-only accessors
like SYMBOL-NAME, and DENOMINATOR although it's hard to see it as
useful in the former case, and it's pretty strange in the later
(and probably indicative of a woefully ineffecient program).
I agree with Moon's analysis, but i disagree that on these grounds
SETF should handle pathname components like LDB handles integers. I
don't think pathnames appear to be sufficiently non-structured that
the read-only-ness of the components should be taken advantage of
in order to permit this hack.
The same goes for symbol-name. As for denominator, it sounds
sufficiently ludicrous that i think it also should be left out, but
only because it seems perverse.
∂22-Oct-85 1546 greek@DEC-HUDSON WITHOUT-INTERRUPTS
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Oct 85 15:34:38 PDT
Date: Tue, 22 Oct 85 12:45:43 EDT
From: greek@DEC-HUDSON
Subject: WITHOUT-INTERRUPTS
To: common-lisp@su-ai
I think if we abandon the name WITHOUT-INTERRUPTS, which has all kinds
of vague conotations, and adopt the name CRITICAL-SECTION, we might
get further in understanding what it ought to do.
- Paul
∂22-Oct-85 1554 gls@THINK-AQUINAS.ARPA Report on trip to Japan
Received: from THINK.COM by SU-AI.ARPA with TCP; 22 Oct 85 15:50:26 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 22 Oct 85 12:41:38 edt
Date: Tue, 22 Oct 85 12:43 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Report on trip to Japan
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851022124308.1.GLS@THINK-DESIDERIUS.ARPA>
Well, my face is red. I did not get to Japan after all. When I
presented my passport at the airport gate in Seattle, I was informed
that the passport contained no visa for travel to Japan. Japan requires
that a visa be obtained in advance of travel. I didn't know this (none
of the European countries I have visited has required a visa), and none
of the many people helping me (and who did many other things to make the
trip possible) thought to advise me to get a visa. My problem occurred
on a Saturday morning, and no Japanese consulate would be open until
Monday, which would be too late; and so my trip was cancelled. Too bad.
This is especially disappointing to me as I had hoped to have some
discussions about means of international cooperation in the development
of Common Lisp. I may be able to try again next spring.
Nevertheless, I am grateful to all of you who supplied me with
implementation data for the survey I conducted in preparation for the
trip. I think the survey was well worth doing. I have distributed it
to this mailing list. Since then a couple more entries have come in,
and I will distribute this addendum in a few days. (Any more out
there?)
It was suggested to me that it might be useful to publish this survey in
some forum such as SIGPLAN Notices or the SIGART newsletter. However, I
made a specific statement up front about the uses to which I would put
the collected data, and I would not feel right about publishing it
without first checking back with all of you who supplied the data.
Questions:
(1) Do you feel it would be useful to publish the collected survey data?
(2) If you supplied data, would you consent to using the data for this
purpose? (Perhaps you may wish to supply a corrected version now that
you have seen all the entries together?)
There remains the question of whether such a journal would wish to publish
the list, but that's another matter.
∂22-Oct-85 1908 gls@THINK-AQUINAS.ARPA Report on trip to Japan
Received: from THINK.COM by SU-AI.ARPA with TCP; 22 Oct 85 15:50:26 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 22 Oct 85 12:41:38 edt
Date: Tue, 22 Oct 85 12:43 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Report on trip to Japan
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851022124308.1.GLS@THINK-DESIDERIUS.ARPA>
Well, my face is red. I did not get to Japan after all. When I
presented my passport at the airport gate in Seattle, I was informed
that the passport contained no visa for travel to Japan. Japan requires
that a visa be obtained in advance of travel. I didn't know this (none
of the European countries I have visited has required a visa), and none
of the many people helping me (and who did many other things to make the
trip possible) thought to advise me to get a visa. My problem occurred
on a Saturday morning, and no Japanese consulate would be open until
Monday, which would be too late; and so my trip was cancelled. Too bad.
This is especially disappointing to me as I had hoped to have some
discussions about means of international cooperation in the development
of Common Lisp. I may be able to try again next spring.
Nevertheless, I am grateful to all of you who supplied me with
implementation data for the survey I conducted in preparation for the
trip. I think the survey was well worth doing. I have distributed it
to this mailing list. Since then a couple more entries have come in,
and I will distribute this addendum in a few days. (Any more out
there?)
It was suggested to me that it might be useful to publish this survey in
some forum such as SIGPLAN Notices or the SIGART newsletter. However, I
made a specific statement up front about the uses to which I would put
the collected data, and I would not feel right about publishing it
without first checking back with all of you who supplied the data.
Questions:
(1) Do you feel it would be useful to publish the collected survey data?
(2) If you supplied data, would you consent to using the data for this
purpose? (Perhaps you may wish to supply a corrected version now that
you have seen all the entries together?)
There remains the question of whether such a journal would wish to publish
the list, but that's another matter.
∂23-Oct-85 0723 BSG@SCRC-YUKON.ARPA WITHOUT-INTERRUPTS
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 07:23:16 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 162582; Wed 23-Oct-85 10:02:46-EDT
Date: Wed, 23 Oct 85 10:07 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 22 Oct 85 12:45-EDT from greek@DEC-HUDSON
Message-ID: <851023100741.6.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Tue, 22 Oct 85 12:45:43 EDT
From: greek@DEC-HUDSON
I think if we abandon the name WITHOUT-INTERRUPTS, which has all kinds
of vague conotations, and adopt the name CRITICAL-SECTION, we might
get further in understanding what it ought to do.
- Paul
No, it hides the issue rather than clarifies it. On a certain class of
simple systems, CRITICAL-SECTION means "without interrupts". When
multiprocessing and other complications are introduced, then
"without interrupts" is not only not sufficiently adequate,
but not sufficiently -specific- as to exactly what must be locked out.
"CRITICAL-SECTION" makes no claim to asserting exactly what must be
locked out, but in no way addresses the problem that this is a
complicated set, either.
∂23-Oct-85 0822 greek@DEC-HUDSON WITHOUT-INTERRUPTS
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85 08:22:02 PDT
Date: Wed, 23 Oct 85 11:28:22 EDT
From: greek@DEC-HUDSON
Subject: WITHOUT-INTERRUPTS
To: common-lisp@su-ai
Mr. Greenberg has pointed out that I've only hidden the problem by
suggesting CRITICAL-SECTION instead of WITHOUT-INTERRUPTS. That's
exactly what I intended to do.
WITHOUT-INTERRUPTS is too specific, and deals only with interrupt
questions, not with memory lockout or other strange things that
may occur on multiprocessors.
CRITICAL-SECTION, I believe, suggests what it is that we are trying
to accomplish, without being specific. On a simple processor running
a LISP without its own tasking or interrupts, it would be a nop.
With interrupts, it would lock them out. With tasks, it would also
prevent task switches. On a multiprocessor it might also do some
kind of memory lockout to prevent the other processors from stomping
on things. Who knows -- and that's exactly the point.
Perhaps the problem is that there are so many classes of things we
want to lock out that we need multiple macros or options to the
one macro.
- Paul
∂23-Oct-85 0947 BSG@SCRC-STONY-BROOK.ARPA WITHOUT-INTERRUPTS
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 09:47:37 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339514; Wed 23-Oct-85 12:25:47-EDT
Date: Wed, 23 Oct 85 12:31 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Oct 85 11:28-EDT from greek@DEC-HUDSON.ARPA
Message-ID: <851023123157.6.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed, 23 Oct 85 11:28:22 EDT
From: greek@DEC-HUDSON
Mr. Greenberg has pointed out that I've only hidden the problem by
suggesting CRITICAL-SECTION instead of WITHOUT-INTERRUPTS. That's
exactly what I intended to do.
WITHOUT-INTERRUPTS is too specific, and deals only with interrupt
questions, not with memory lockout or other strange things that
may occur on multiprocessors.
CRITICAL-SECTION, I believe, suggests what it is that we are trying
to accomplish, without being specific. On a simple processor running
a LISP without its own tasking or interrupts, it would be a nop.
With interrupts, it would lock them out. With tasks, it would also
prevent task switches. On a multiprocessor it might also do some
kind of memory lockout to prevent the other processors from stomping
on things. Who knows -- and that's exactly the point.
As you hint in the next paragraph, it's not a question of "who knows",
but an issue of different kinds of outlocking being appropriate at
different times, on a more complicated system
Perhaps the problem is that there are so many classes of things we
want to lock out that we need multiple macros or options to the
one macro.
Exactly, if we decide that the problem has to be addressed by the
language at all. Unless CRITICAL-SECTION has a bunch of options,
it addresses -no- problems. It is not clear to me that the
conceptual options can be stated in a system-independent way.
I am not willing to say that I know about all the tasking and
processor-sharing paradigms that have been, or might be invented.
- Paul
∂23-Oct-85 1023 greek@DEC-HUDSON WITHOUT-INTERRUPTS
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85 10:19:09 PDT
Date: Wed, 23 Oct 85 13:25:24 EDT
From: greek@DEC-HUDSON
Subject: WITHOUT-INTERRUPTS
To: common-lisp@su-ai
Mr. Greenberg is certainly correct when he says we don't understand
all the locking mechanisms that exist. However, unless I'm off
base here, it seems to me that CRITICAL-SECTION could be specified
as locking out ANY possible contention from other tasks, interrupt
handlers, processors, etc. If a particular implementation needs
additional kinds of locking macros, they can add them.
Perhaps we should define CRITICAL-SECTION as follows:
CRITICAL-SECTION (&key options) &body body
and say that, without options, it locks out "everything". On the other
hand, perhaps "everything" is simply too nebulous.
- Paul
∂23-Oct-85 1030 Moon@SCRC-STONY-BROOK.ARPA WITHOUT-INTERRUPTS
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 10:30:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339575; Wed 23-Oct-85 13:31:08-EDT
Date: Wed, 23 Oct 85 13:32 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Oct 85 11:28-EDT from greek@DEC-HUDSON
Message-ID: <851023133207.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I seem to have come in in the middle of this discussion. Perhaps there
was some earlier mail that I missed for some reason.
I think WITHOUT-INTERRUPTS, or any other multiprocessing primitive, is
much too implementation-dependent to be appropriate for the portable
Common Lisp language. I don't see any point in discussing it, because
there is no possible primitive that will meet the needs of all multiprocessing
implementation techniques.
Date: Wed, 23 Oct 85 11:28:22 EDT
From: greek@DEC-HUDSON
On a simple processor running
a LISP without its own tasking or interrupts, it would be a nop.
With interrupts, it would lock them out. With tasks, it would also
prevent task switches. On a multiprocessor it might also do some
kind of memory lockout to prevent the other processors from stomping
on things.
So what we have is that on some uniprocessors WITHOUT-INTERRUPTS or
CRITICAL-SECTION, it matters not at all what you call it, is
meaningless, on other uniprocessors it makes sense, and on large
multiprocessors it is so expensive to implement that no one will ever
use it. If instead you decide to make a primitive that specifies more
precisely what synchronization is required, so that the implementation
will not be so expensive, you will have to build in assumptions about
some particular multiprocessor architecture. There are an enormous
number of possible architectures, many of them advocated as the best
by people of strong convictions, and no agreement at present on unifying
general principles.
Who knows -- and that's exactly the point.
Mine too.
This issue is simply outside the scope of what Common Lisp can hope to address.
∂23-Oct-85 1110 Moon@SCRC-STONY-BROOK.ARPA WITHOUT-INTERRUPTS
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 11:10:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339615; Wed 23-Oct-85 14:07:38-EDT
Date: Wed, 23 Oct 85 14:08 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Oct 85 13:25-EDT from greek@DEC-HUDSON.ARPA
Message-ID: <851023140830.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 23 Oct 85 13:25:24 EDT
From: greek@DEC-HUDSON
Mr. Greenberg is certainly correct when he says we don't understand
all the locking mechanisms that exist. However, unless I'm off
base here, it seems to me that CRITICAL-SECTION could be specified
as locking out ANY possible contention from other tasks, interrupt
handlers, processors, etc. If a particular implementation needs
additional kinds of locking macros, they can add them.
Perhaps we should define CRITICAL-SECTION as follows:
CRITICAL-SECTION (&key options) &body body
and say that, without options, it locks out "everything". On the other
hand, perhaps "everything" is simply too nebulous.
Let me just ask you to think about one thing and then I promise not to send
any more mail.
In Lisp on VAX/VMS, will CRITICAL-SECTION stop VMS from scheduling any processes
that have shared global sections mapped into their address space that are also
mapped into the address space of this Lisp?
∂23-Oct-85 1258 greek@DEC-HUDSON WITHOUT-INTERRUPTS
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85 12:58:35 PDT
Date: Wed, 23 Oct 85 16:04:59 EDT
From: greek@DEC-HUDSON
Subject: WITHOUT-INTERRUPTS
To: common-lisp@su-ai
I too promise that this is my last message.
Mr. Moon is right -- VMS certainly couldn't promise to lock out
other processes that might touch a shared section. Somehow that
doesn't bother me, however. We can't worry about other processes
that have nothing to do with LISP -- that's too implementation
specific.
Yeah, sure, this is getting ridiculous. I begin to agree that
WITHOUT-INTERRUPTS is hopeless for a portable language.
- Paul
∂24-Oct-85 1036 gls@THINK-AQUINAS.ARPA WITHOUT-INTERRUPTS: my last message
Received: from THINK.COM by SU-AI.ARPA with TCP; 24 Oct 85 08:38:32 PDT
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 24 Oct 85 11:40:21 edt
Date: Thu, 24 Oct 85 11:42 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: WITHOUT-INTERRUPTS: my last message
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 23 Oct 85 16:04-EDT from greek@DEC-HUDSON
Message-Id: <851024114209.1.GLS@THINK-JEHOSEPHAT.ARPA>
Comment: Remailed at SU-AI after delay caused by distribution list error.
Date: Wed, 23 Oct 85 16:04:59 EDT
From: greek@DEC-HUDSON
I too promise that this is my last message.
Me, too.
Mr. Moon is right -- VMS certainly couldn't promise to lock out
other processes that might touch a shared section.
Sure it could... if it wanted to. Alternatively, the LISP could
simply refuse to share.
On the third hand, suppose I want to swap the names of two files,
so I do
(critical-section
(rename-file "foo" "temp")
(rename-file "bar" "foo")
(rename-file "temp" "bar"))
Assuming that files foo and bar both existed to begin with, am I guaranteed
that at no time can any other process get the value NIL for
(and (probe-file "foo") (probe-file "bar"))
? That would be an awfully nice property to have.
--Guy
∂24-Oct-85 1042 GJC@MIT-MC.ARPA WITHOUT-INTERRUPTS
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 09:40:19 PDT
Date: Thu, 24 Oct 85 12:42:03 EDT
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Wed 23 Oct 85 13:25:24 EDT from greek at DEC-HUDSON
Message-ID: <[MIT-MC.ARPA].691403.851024.GJC>
Comment: Remailed at SU-AI after delay caused by distribution list error.
Without-Interrupts can be very confusing. On the LISPM for example it
is possible to call, knowingly or unknowingly, PROCESS-WAIT from within
a Without-Interrupts, this can then allow a process switch, which
may or may not defeat the purpose of the without-interrupts.
On the VAX, in VAX-NIL which I'm most familiar with, I would be
worried about critical sections of code from the point of view of
AST handlers and such. However, I know that in NIL, by default,
any straight line sequence of code without a function call is
exectuted without testing for the interrupt polling BIT, or, while
writing (or compiling lisp to) LMI-LAMBDA microcode there are similar
considerations, therefore I can take advantage of this condition in
writing code that has possible interlocking dangers. But conditions
are so different in the different lisps that a simple-looking PORTABLE
construct such as CRITICAL-SECTION would not work. Those very people
who would want to use it are probably those that couldnt understand
the underlying mechanisms sufficiently to write such code correctly
and portably.
Instead, maybe a few primitive datastructures, such as QUEUE's with
properly interlocked manipulation primitives could be introduced into
the language. That is to say, what kinds of things are you wanting to
use CRITICAL-SECTION for anyway?
∂25-Oct-85 1337 RPG Meeting
To: common-lisp@SU-AI.ARPA
I am at this very moment in negotiations with hotels and the like
in the Boston area regarding the exact dates for the meeting. I expect
to get some definitive answer to the question of ``when?'' by Monday
or Tuesday. As it happens, it is not always possible to pick the exact
days only 1.5 months in advance.
-rpg-
∂26-Oct-85 1315 RPG Tentative Schedule for the Common Lisp Meeting
To: common-lisp@SU-AI.ARPA
I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts,
for December 16, 17, and 18 for the meeting (not for accommodations).
Are these dates acceptable? I must have a firm answer by monday.
-rpg-
∂28-Oct-85 0855 masinter.pa@Xerox.ARPA Re: Tentative Schedule for the Common Lisp Meeting
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 08:55:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 OCT 85 08:57:08 PST
Date: 28 Oct 85 09:03 PST
From: masinter.pa@Xerox.ARPA
Subject: Re: Tentative Schedule for the Common Lisp Meeting
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 26 Oct 85 13:15
PDT
To: RPG@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <851028-085708-2075@Xerox>
What happened to the week of December 3? You changed the date without a
lot of discussion....
∂28-Oct-85 1233 OLDMAN@USC-ISI.ARPA Uniqueness of &rest arguments
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 12:32:12 PST
Date: 28 Oct 1985 15:32-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: Uniqueness of &rest arguments
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]28-Oct-85 15:32:44.OLDMAN>
Are &rest arguments guaranteed to be copied? Consider the following:
(defmacro m (&rest args)
`',(nreverse args) ; Destructive reverse
)
(setq x '(m a b c d))
(eval x)
What is the final value of x? I think that I would argue that
it is undefined since args may or may not be a copy of the original
form. Is there anything in Cttl that clarifies this?
-- Dan
∂28-Oct-85 1445 gls@THINK-AQUINAS.ARPA Uniqueness of &rest arguments
Received: from THINK.COM by SU-AI.ARPA with TCP; 28 Oct 85 14:45:15 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Mon, 28 Oct 85 16:07:57 est
Date: Mon, 28 Oct 85 16:09 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Uniqueness of &rest arguments
To: OLDMAN@USC-ISI.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <[USC-ISI.ARPA]28-Oct-85 15:32:44.OLDMAN>
Message-Id: <851028160902.2.GLS@THINK-DESIDERIUS.ARPA>
Date: 28 Oct 1985 15:32-EST
From: OLDMAN@USC-ISI.ARPA
Are &rest arguments guaranteed to be copied? Consider the following:
(defmacro m (&rest args)
`',(nreverse args) ; Destructive reverse
)
(setq x '(m a b c d))
(eval x)
What is the final value of x? I think that I would argue that
it is undefined since args may or may not be a copy of the original
form. Is there anything in Cttl that clarifies this?
-- Dan
I cannot find any place in the manual that addresses this point. The
text describing APPLY alludes to appending the last argument to APPLY to
a list of all other arguments (except the function, of course), and so
one might think, referring to the definition of APPEND, that the
resulting list of arguments might contain actual cons cells from the
list that is the last argument to APPLY. However, nothing addresses
whether a &REST argument might share with this list.
My own opinion is that indeed the args might not be a copy of the
original form, but I regard this as a non-trivial clarification worthy
of discussion.
--Guy
∂28-Oct-85 1711 Moon@SCRC-STONY-BROOK.ARPA Uniqueness of &rest arguments
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 17:11:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 343004; Mon 28-Oct-85 20:06:37-EST
Date: Mon, 28 Oct 85 20:07 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Uniqueness of &rest arguments
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: OLDMAN@USC-ISI.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <851028160902.2.GLS@THINK-DESIDERIUS.ARPA>
Message-ID: <851028200712.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 28 Oct 85 16:09 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: 28 Oct 1985 15:32-EST
From: OLDMAN@USC-ISI.ARPA
Are &rest arguments guaranteed to be copied? Consider the following:
(defmacro m (&rest args)
`',(nreverse args) ; Destructive reverse
)
(setq x '(m a b c d))
(eval x)
What is the final value of x? I think that I would argue that
it is undefined since args may or may not be a copy of the original
form. Is there anything in Cttl that clarifies this?
I cannot find any place in the manual that addresses this point. The
text describing APPLY alludes to appending the last argument to APPLY to
a list of all other arguments (except the function, of course), and so
one might think, referring to the definition of APPEND, that the
resulting list of arguments might contain actual cons cells from the
list that is the last argument to APPLY. However, nothing addresses
whether a &REST argument might share with this list.
None of this applies to macros anyway, since they aren't invoked with APPLY.
My own opinion is that indeed the args might not be a copy of the
original form, but I regard this as a non-trivial clarification worthy
of discussion.
I hope it doesn't take a whole lot of discussion. It's pretty clear to me
that if the manual doesn't guarantee explicitly that the user can freely
bash the &rest argument, then the user can only sensibly assume that it is
not safe to bash it. I also can't see any significant advantage to the user
to be gained requiring implementations to make copies of &rest arguments.
Note that if there are implementations that can't avoid making a copy (but
not for macros!), they can easily have a compiler optimizer to remove
calls to copy-list, so there can be no argument from efficiency.
∂28-Oct-85 1715 Moon@SCRC-STONY-BROOK.ARPA Tentative Schedule for the Common Lisp Meeting
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 17:15:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 343009; Mon 28-Oct-85 20:14:50-EST
Date: Mon, 28 Oct 85 20:15 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Tentative Schedule for the Common Lisp Meeting
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 26 Oct 85 16:15-EDT from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851028201531.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 26 Oct 85 1315 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts,
for December 16, 17, and 18 for the meeting (not for accommodations).
Are these dates acceptable?
They appear to be okay for me.
I must have a firm answer by monday.
By when? You can't have meant today if you sent mail on Saturday. Do you
mean next Monday?
∂29-Oct-85 1649 hoey@nrl-aic Default scope of references
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 16:48:53 PST
Date: 29 Oct 1985 18:09:05 EST (Tue)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Default scope of references
To: Common-lisp@SU-AI.ARPA
Message-Id: <499475345/hoey@nrl-aic>
I would like some protection against accidental references to
dynamically bound variables in interpreted code. Compilers typically
complain about such lossage. When I heard that Common Lisp defaulted
to lexical binding, I thought that was what was meant. For instance,
given
(DEFVAR *TEST-1* '(PROGN (DEFUN SET-FOO (VAL)
(SETQ FOO VAL))
(SET-FOO NIL)))
(DEFVAR *TEST-2* '(PROGN (SET 'FOO T)
(DEFUN GET-FOO ()
FOO)
(GET-FOO)))
in the absence of (PROCLAIM (SPECIAL FOO)), I somehow expected that
(EVAL *TEST-1*) and (EVAL *TEST-2*) would each tell me that I was
accessing a variable that was neither declared special nor lexically
bound. According to CLtL, however, ``The general rule is that if the
symbol occurs textually within a program construct that creates a
*binding* for a variable of the same name, then the reference is to the
variable specified by the binding; if no such program construct
textually contains the reference, then it is taken to refer to the
special variable of that name.'' [p. 55] Thus these forms are
supposedly legally evaluable. Is this what was intended? Should
evaluation of these forms be or signal an error? I would certainly
hope that the answer is the same for both tests.
The CL interpreters I have seen signal an error in (EVAL *TEST-1*);
they are happy to let (EVAL *TEST-2*) modify the global value of FOO.
A funnier situation occurs when we have
(DEFVAR *TEST-3* '(PROGN (EVAL (BUTLAST *TEST-1*))
(DEFUN LEX-TEST ()
(LET ((FOO T))
(SET-FOO NIL)
FOO))
(LEX-TEST)))
I have actually seen an implementation for which (EVAL *TEST-3*) yields
NIL, but that is clearly erroneous. Other implementations happily
evaluate *TEST-3* to T, setting the global value of FOO to NIL. A
stranger situation occurs with
(DEFVAR *TEST-4* '(PROGN (EVAL (BUTLAST *TEST-3*))
(COMPILE 'LEX-TEST)
(LEX-TEST)))
In the implementations I have tested, (EVAL *TEST-4*) will signal an
error when SET-FOO attempts to change the value of FOO.
Unfortunately, my access to Common Lisp implementations is confined to
one vendor's Beta release and two other implementations to which I have
no hands-on access. Rather than disparage anyone's implementation on
such slender evidence, I would like to hear from implementors on the
results of evaluating the four tests in the most current versions of
their implementations.
Dan
∂30-Oct-85 0545 jeff%aiva.edinburgh.ac.uk@ucl-cs.ARPA Re: Tentative Schedule for the Common Lisp Meeting
Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 05:45:14 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000666; 30 Oct 85 12:26 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@ucl-cs.arpa>
Date: Tue, 29 Oct 85 19:18:29 GMT
To: RPG@su-ai.arpa, common-lisp@su-ai.arpa
Subject: Re: Tentative Schedule for the Common Lisp Meeting
|Date: 26 Oct 85 1315 PST
|From: Dick Gabriel <RPG@arpa.su-ai>
|Subject: Tentative Schedule for the Common Lisp Meeting
|
|I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts,
|for December 16, 17, and 18 for the meeting (not for accommodations).
|Are these dates acceptable? I must have a firm answer by monday.
| -rpg-
I know this is after monday, but I'm going to send it anyway. For flying
transatlantic, the 16-18 have the advantage of being over a month away
so that it's possible to buy a reasonable ticket. But they are almost
certainly into the busy (and expensive) season. (Last year fares went up
the 13th and then down again around the 27th.) Still, this way I need
stay only a week to be home for Christmas.
The dates are acceptable, though.
Cheers,
Jeff Dalton
AIAI, University of Edinburgh
∂30-Oct-85 0632 GJC@MIT-MC.ARPA Default scope of references
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 06:31:16 PST
Date: Wed, 30 Oct 85 09:33:12 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: Default scope of references
To: hoey@NRL-AIC.ARPA
cc: Common-lisp@SU-AI.ARPA
In-reply-to: Msg of 29 Oct 1985 18:09:05 EST (Tue) from Dan Hoey <hoey at nrl-aic.ARPA>
Message-ID: <[MIT-MC.ARPA].698107.851030.GJC>
In the LMI Systems that you have the behavior of your test cases is
controlled by the variable
SI::*ALL-FREE-INTERPRETER-VARIABLE-REFERENCES-SPECIAL*, which
defaults to NIL. With this default setting both cases *TEST-1* and
*TEST-2* signal errors as you wish. There was some discussion about
getting rid of this option, or at least defaulting it to T. In
DOE-MACSYMA for example the setting of this variable must be T,
because of the unrestricted use of EVAL in the pattern matcher code.
The VAX-NIL system system took a different tack, prefering to be
somewhat like the usual compiler approach. An undeclared (SETQ FOO
...) will generate a warning, and then a "FOO assumed special." This
also has its drawbacks.
There is the issue of how correct to be vs how much trouble to
cause users with old habits. Many users of the LMI system set the
variable controlling the behavior to T. Your reported results are not
consistent with the behavior of LMI systems in either setting. Both
variable reference and variable setting are caught, but you report
that variable setting is not caught. Perhaps you evaluated (SET-FOO)
in a lisp-listener instead of as (EVAL '(SET-FOO)). These have
different behaviors because the system is trying to be more forgiving
to top-level calls than to constructs inside programs.
-gjc
∂30-Oct-85 1013 JAR@MIT-MC.ARPA absence of (declare (unspecial ...))
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 10:13:10 PST
Date: Wed, 30 Oct 85 13:15:05 EST
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject: absence of (declare (unspecial ...))
To: Common-Lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].698338.851030.JAR>
While we're on the subject of lexical versus special, I'd like to ask if
anyone remembers why there's no UNSPECIAL declaration in Common Lisp.
It seems important enough that there must have been some compelling
reason for its omission.
∂30-Oct-85 1142 DLW@SCRC-STONY-BROOK.ARPA Default scope of references
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 11:42:20 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 344503; Wed 30-Oct-85 14:42:51-EST
Date: Wed, 30 Oct 85 14:44 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Default scope of references
To: hoey@NRL-AIC.ARPA, Common-lisp@SU-AI.ARPA
In-Reply-To: <499475345/hoey@nrl-aic>
Message-ID: <851030144425.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 29 Oct 1985 18:09:05 EST (Tue)
From: Dan Hoey <hoey@nrl-aic.ARPA>
In Symbolics Common Lisp, *test-1* returns NIL, *test-2* returns T,
*test-3* returns T, and *test-4* returns T. No errors are signalled.
As far as I understand the definition of the language, this is correct.
∂30-Oct-85 1225 RWK@SCRC-YUKON.ARPA Default scope of references
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 12:25:26 PST
Received: from CROW.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 165515; Wed 30-Oct-85 15:28:22-EST
Date: Wed, 30 Oct 85 15:25 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Default scope of references
To: Dan Hoey <hoey@NRL-AIC.ARPA>
cc: Common-lisp@SU-AI.ARPA
In-Reply-To: <499475345/hoey@nrl-aic>
Message-ID: <851030152528.6.RWK@CROW.SCRC.Symbolics.COM>
Date: 29 Oct 1985 18:09:05 EST (Tue)
From: Dan Hoey <hoey@nrl-aic.ARPA>
(DEFVAR *TEST-1* '(PROGN (DEFUN SET-FOO (VAL)
(SETQ FOO VAL))
(SET-FOO NIL)))
(eval *test-1*)
==> NIL
foo
==> NIL
(DEFVAR *TEST-2* '(PROGN (SET 'FOO T)
(DEFUN GET-FOO ()
FOO)
(GET-FOO)))
(eval *test-1*)
==> NIL
foo
==> NIL
in the absence of (PROCLAIM (SPECIAL FOO)), I somehow expected that
(EVAL *TEST-1*) and (EVAL *TEST-2*) would each tell me that I was
accessing a variable that was neither declared special nor lexically
bound. According to CLtL, however, ``The general rule is that if the
symbol occurs textually within a program construct that creates a
*binding* for a variable of the same name, then the reference is to the
variable specified by the binding; if no such program construct
textually contains the reference, then it is taken to refer to the
special variable of that name.'' [p. 55] Thus these forms are
supposedly legally evaluable. Is this what was intended?
Yes.
Should
evaluation of these forms be or signal an error?
No.
I would certainly
hope that the answer is the same for both tests.
It is.
(DEFVAR *TEST-3* '(PROGN (EVAL (BUTLAST *TEST-1*))
(DEFUN LEX-TEST ()
(LET ((FOO T))
(SET-FOO NIL)
FOO))
(LEX-TEST)))
(eval *test-3*)
==> T
foo
==> NIL
(DEFVAR *TEST-4* '(PROGN (EVAL (BUTLAST *TEST-3*))
(COMPILE 'LEX-TEST)
(LEX-TEST)))
(eval *test-4*)
==> T
foo
==> NIL
I believe the "best" alternative is what VAX/NIL does; namely
give a warning like the compiler. (It would be best if it
did it only once for a given form). However, this might be
unpopular with users if this warning interferes with their
interaction.
Of course, the real conclusion to draw from this is to
use the compiler. Most compilers give you a lot of
static error checking that you won't see interpreted.
For example, if your compiler does wrong-number-of-args
checking, it will check the number of arguments even on
parts of your function that are only called once in a blue
moon.
∂31-Oct-85 0847 MLY@MIT-MC.ARPA free variable references in interpreter.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 08:47:35 PST
Date: Thu, 31 Oct 85 11:49:30 EST
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject: free variable references in interpreter.
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].699862.851031.MLY>
GJC has somewhat misstated what happens both in NIL and in the MIT
(lmi) lisp machine interpreters.
The initial decision about whether a free variable reference should be
considered "an error" is made by looking at the environment in which
the form was evaluated, not at a magic variable.
"Top-level" evaluation (the sort of thing the user types at a lisp
listener) passes EVAL an environment object which says `just silently
take any free variable references to be a reference to the special
value of that variable' (which is exactly the same as the mechanism
of function lookup, incidentally)
On the other kettle of fish, "normal" evaluation, made in the null
lexical environment, (EVAL's default) signals an error when a free
variable reference occurs. (The variable GJC mentioned,
si::*mumble-free-mumble-reference-mumble-special, is used to override
this for the use truly crufty old code which nobody wants to invest
any time in improving. Anybody else seen binding it should be shot
with a gun)
The result of this is that a user may type "(setq foo *)" and
"(funcall (frob foo) 1)" at a lisp listener without being harrassed
too unduly, but that compiler-style detection of wild references
happens for "(eval '(setq foo *))" and so forth.
[The older way in which NIL's evaluator dealt with this situation,
(explicitly doing a (PROCLAIM '(SPECIAL ...)) and printing a warning
to *ERROR-OUTPUT* whenever the interpreter saw a free reference) was
flushed some time ago in favour of the above scheme]
[Another hack is that that the environment object in the lisp machine
implementation can also flag that -all- variable references are
special. This was intended to be used when people were converting
code which ran with the old dynamic interpreter. As it happened, not
much seemed to require this sort of degenerate backwardness]
∂31-Oct-85 0947 FAHLMAN@C.CS.CMU.EDU free variable references in interpreter.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 Oct 85 09:46:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Oct 85 12:48:36-EST
Date: Thu, 31 Oct 1985 12:48 EST
Message-ID: <FAHLMAN.12155549655.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Richard Mlynarik <MLY@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: free variable references in interpreter.
In-reply-to: Msg of 31 Oct 1985 11:49-EST from Richard Mlynarik <MLY at MIT-MC.ARPA>
The default behavior of the LMI/MIT version of the Lisp Machine code, as
described by MLY and GJC, is not legal Common Lisp as I understand the
manual (page 55). In Common Lisp, references to variables not lexically
bound in the current environment are supposed to refer to the special
value of that variable, and should not generate an error (unless the
special variable has no current value). This is true whether or not the
reference occurs at top level. One can argue about whether the LMI
behavior is better, but it is not Common Lisp. At least they provide a
switch which makes the system conform to Common Lisp in this matter, but
I find disturbing the sentiment that anyone setting this switch, except
when dealing with "crufty old code" should be shot, at least if LMI is
advertising their system as a Common Lisp. In that case, I think that
Common Lisp compatibility should be the default.
-- Scott
∂31-Oct-85 1551 GJC@MIT-MC.ARPA free variable references in interpreter.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 15:51:34 PST
Date: Thu, 31 Oct 85 18:53:27 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: free variable references in interpreter.
To: Fahlman@C.CS.CMU.EDU
cc: MLY@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 31 Oct 1985 12:48 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MIT-MC.ARPA].700350.851031.GJC>
The purpose of the interpreter behavior was to be compatible with
compiler behavior that has been the accepted standard for years,
to warn or give some indication on UNDECLARE SPECIAL VARIABLES.
This should be obvious. It has been an invaluable aid in
tracking down problems in code being converted to common-lisp
and I recommend it as an option for everybody.
The default-behavior issue has nothing to do with advertising, it has
to do with the mechanics of customer support. There are two possible
settings, T and NIL. If set to NIL then users will quickly find
problems in their code relating to undeclared variables that are both
globally set and lambda bound. If set to T then most of these common
problems with scoping become more subtle, and instead turn into
lengthy phone calls. In the more rare cases you find someone that
really wants to do (SET 'FOO <x>) then (EVAL <something with FOO>).
This might happen in a production rule system for example. In these
cases we get the chance to advise people to put in the call to
PROCLAIM.
But serious folks. There is a lot more to find disturbing about MLY
than his sentiments. Maybe we'll all get a chance to take our shots
at the next common-lisp meeting.
Let me propose one of my sentiments:
Any lispmachine company that would advertise their machine just:
"AS A COMMON LISP"
would be underselling it severely. lispmachine companies generally
seem to be saying things along the lines of "SUPPORTS COMMON LISP"
or "RUNS CODE CONFORMING TO THE ..."
But what justifies your too disparaging tone "at least they provide a
switch...?" Give us some credit here where credit is due, it is
rather that "OF COURSE THEY PROVIDE A SWITCH!!" This is a minor
stylistic difference we have here, not something to get yourself
worked up about, bordering on insult.
There is the letter of the law here vs the intent. One of the major
intents of CL was to have interpreter/compiler compatibility. The
purpose of the LMI switch was merely along these lines.
Isn't much better in the long run to view the CL book as a constitution rather
than as a statement of dogma?
∂31-Oct-85 1820 FAHLMAN@C.CS.CMU.EDU free variable references in interpreter.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 Oct 85 18:20:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Oct 85 21:22:43-EST
Date: Thu, 31 Oct 1985 21:22 EST
Message-ID: <FAHLMAN.12155643250.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA, MLY@MIT-MC.ARPA
Subject: free variable references in interpreter.
In-reply-to: Msg of 31 Oct 1985 18:53-EST from George J. Carrette <GJC at MIT-MC.ARPA>
But what justifies your too disparaging tone "at least they provide a
switch...?" Give us some credit here where credit is due, it is
rather that "OF COURSE THEY PROVIDE A SWITCH!!" This is a minor
stylistic difference we have here, not something to get yourself
worked up about, bordering on insult.
I wasn't trying to insult anybody. (When I am trying to insult someone,
I generally do a better job of it than this.) I just didn't want people
seeing this exchange to assume that the behavior you and MLY described
was legal Common Lisp, and that it really is an error to reference an
undeclared special. Your post gave that impression, and MLY compounded
the problem by saying that the switch in question was only to be used
for backwards compatibility. So my statement was that the default
behavior you described was not, strictly speaking, legal Common Lisp. I
also said that "at least" your system provided a switch in it that would
turn on the legal behavior, though MLY had just said that anyone using
that switch should be shot. The "at least" meant "at least the
switch is there, though some believe that it shouldn't be used."
I happen to agree that it is lousy style to reference undeclared
specials, and I think it is a useful feature in a Common Lisp
implementation to have a mode available where such things get flagged.
I personally would not make this the default, but that is a minor issue.
The more important question is to what extent we should encourage small
improvements that happen to violate the Common Lisp standard, such as it
is. I have no quarrel with any manufacturer who wants to stand up and
say clearly in their documentation that "we have chosen to deviate from
the Common Lisp standard in the following N ways because we feel that
these changes are improvements". Maybe LMI has done this; I haven't
seen their documentation. But if such small deviations, however
well-meaning, are made without proper acknowledgement, they constitute a
real threat to the standardization of the language. That's why I try to
flag these things when I see them.
-- Scott
∂31-Oct-85 1858 GSB@MIT-MC.ARPA free variable references in interpreter.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 18:58:46 PST
Date: Thu, 31 Oct 85 22:00:45 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
Subject: free variable references in interpreter.
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].700561.851031.GSB>
In NIL we had at least two years of experience with automatic special
declarations of free variables. What used to happen was a free
reference would cause, on the first occurrence, a warning message to
be printed, and a special proclamation to be performed. This was a
big pain and caused a fair amount of grief.
Now, what happens is that a free variable reference generates a
free-variable-reference error. The result of this is that the user
gets to choose (via the debugger) to globally declare the variable
special, to just use the special value "just this once" (i.e., the
error will occur again), or any other general debugger action. It
seems fair to me that you should be warned about a free variable which
is not declared within the current lexical scope. Remember that the
compiler cannot tell what dynamic scope the function will be called
in, so (in the interpreter) blindly and silently using whatever
dynamic value is around doesn't seem to me to be such a hot idea.
And, "OF COURSE IT'S CONTROLLED BY A SWITCH!!!" --
si::*interpreter-special-warn*.
And, as MLY said, we also have special dispensation for the toplevel
null lexical environment to utilize free variables without this
interference, so that one can do things like
(setq x ...)
without globally corrupting the usage of X. (If you want to, you use
defparameter instead.)
----------------
I would appreciate it if other people would refrain from describing
what NIL does when they are at all unfamiliar with the development
version. It is unfortunate that the latest public NIL release came
out 1.5 years ago and the published benchmarks for some reason were
those for the version before that, so i don't need any additional help
in the spread of misinformation.
∂01-Nov-85 0846 gls@THINK-AQUINAS.ARPA free variable references in interpreter.
Received: from THINK.COM by SU-AI.ARPA with TCP; 1 Nov 85 08:46:17 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 1 Nov 85 11:48:22 est
Date: Fri, 1 Nov 85 11:49 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: free variable references in interpreter.
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12155643250.BABYL@C.CS.CMU.EDU>
Message-Id: <851101114946.2.GLS@DESIDERIUS.THINK.COM>
I don't believe there is anything in the Common Lisp book that
explicitly states that a Common Lisp implementation may not signal
errors in any situations not explicitly defined in the book to be
errors. On tbe other hand, I think there is at least an implicit
expectation that a purely computational section of a valid Common Lisp
program will execute without requiring the user to hit a "resume" key
every three seconds. I am not sure what we can say in the book about
this without unduly contraining experimentation with programming
environments and debugging tools.
Here is a set of thought experiments about a LISP system. Question: in
each case, is it or is is not consistent with the letter and/or the
spirit of Common Lisp? There are two subcases for each experiment,
according to whether the interpreter or compiler is involved. I will
use the noun "system" to refer to either the interpreter of the
compiler, and I will use "warning" to mean any action that draws the
user's attention to a message (and that may or may not require explicit
user action before continuing with the computation). Some of these
examples are intentionally outlandish.
(1) You refer to a function without declaring it first, and the system
gives you a warning. (Note that I said "declaring", not "defining".
Consider the compiler especially.)
(2) You refer to a special variable without declaring it, and the system
gives you a warning.
(3) You write "(+ x (cons y z))" and the system warns you that CONS
cannot produce (or has not produced) a value that is valid as an
argument to +.
(4) You write
(COND ((ATOM X) 'A) (T 'C) ((BAZ X) 'D))
and the system warns you that the last COND clause is unreachable.
(5) You write
(COND ((ATOM X) 'A) ((CONSP X) 'C) ((BAZ X) 'D))
and the system warns you that the last COND clause is unreachable.
(6) You write
(MULTIPLE-VALUE-BIND (A B C) (FLOOR X Y) ...)
and the system warns you that FLOOR returns only two values.
(7) You use several GO's in a PROG, and the system warns you that this
code will probably be very hard to maintain.
(8) You write
(DEFUN FIB (N)
(COND ((<= N 1) 1)) ;Note parenthesis error!
(T (+ (FIB (- N 1)) (FIB (- N 2)))))
and the system warns you that your code is not properly indented.
(9) You write
(DEFUN FIB (N)
(COND ((<= N 1) 1)
(T (+ (FIB (- N 1))
(FIB (- N 2))))))
and the system warns you that your code is not properly indented.
(10) You write a DO loop, and the system warns you that it could have
been expressed more simply and efficiently by using a call to RASSOC
with the :TEST-NOT and :KEY options.
(11) You write two nested DO loops, and the system warns you that the
SORT primitive is much better than the bubble sort that you wrote.
(12) You write
(DEFUN FIB (N) (IF (ZEROP N) 1 (* N (FIB (- N 1)))))
and the system warns you that your function FIB is computing factorials
and not Fibonacci numbers.
Is there some generalization we can derive from these thought
experiments, or others, that is worth putting in the book?
--Guy
∂01-Nov-85 1136 FAHLMAN@C.CS.CMU.EDU free variable references in interpreter.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Nov 85 11:36:04 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 Nov 85 14:37:33-EST
Date: Fri, 1 Nov 1985 14:37 EST
Message-ID: <FAHLMAN.12155831623.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: free variable references in interpreter.
In-reply-to: Msg of 1 Nov 1985 11:49-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
I don't believe there is anything in the Common Lisp book that
explicitly states that a Common Lisp implementation may not signal
errors in any situations not explicitly defined in the book to be
errors. On tbe other hand, I think there is at least an implicit
expectation that a purely computational section of a valid Common Lisp
program will execute without requiring the user to hit a "resume" key
every three seconds. I am not sure what we can say in the book about
this without unduly contraining experimentation with programming
environments and debugging tools.
If Common Lisp is to be of any value at all as a standard promoting
portable software, the following assumption has to be true (or as close
to true as we can possibly make it): If an implementation claims to be a
Common Lisp or a superset of Common Lisp, any legal program that
conforms to what is in the manual and uses nothing that is not in the
manual ought to run in that implementation. "Run" means "run without
signalling any errors". I'm not sure we need Guy's hedge about "purely
computational"; I don't know what he means by that, but if he means "not
involving user-interface or system-interface" issues, I think we have
excluded most of that from the current language spec, and have indicated
the range of permissible variation in the remaining cases.
Of course, this is more a goal than an iron-clad rule, since the manual
is ambiguous and incomplete in some areas. Still, I think that we
should state this explicitly and strive to achieve it. I thought that
we already had stated this or something close to it, but maybe not. On
the question of how we say this without unduly constraining
experimentation, I don't see that as a problem. People should feel free
to experiment all they want, but if they knowingly violate the standard
they should point that out and not claim to be a Common Lisp (in those
specific respects). Manufactuers would be well-advised to provide a
mode that that is strictly kosher Common Lisp -- as close as they can
come, anyway -- and if they want to experiment with incompatible
improvements, these should be enabled by a switch of some sort.
Ideally, it should be straightforward to get at the strict Common Lisp;
you should not have to poke around setting 53 undocumented switches,
some of them guarded by people with guns, in order to get behavior that
conforms to the standard.
Given the above, I think I can answer all of Guy's queries with a single
statement of principle:
When operating as a strict Common Lisp, the system should run any legal
Common Lisp program without signalling any ERRORS. If the system wants
to mumble warnings and critiques of my style, that's fine -- the more,
the better -- as long as these warnings are of a sort that I am free to
turn them off or at least ignore them. If the warnings require some
explicit action in order for me to proceed, or if they cause my
compilation not to complete properly, then that is not OK, unless this
is an optional behavior that I can easily get rid of. I don't mind the
intereter mumbling warnings (into some separate stream, so that they
don't mess up what my legal but unstylish program is trying to print),
though customers will have varying opinions about how much they want to
pay for such criticism at runtime.
Doesn't that cover it? I think that Guy threw us a curve by asking
whether warnings were OK in various situations, while saying that these
"warnings" might or might not require some explicit action -- to me, that
is the critical issue.
Of course, a few of Guy's examples are so outlandish that I would find
the warnings in question irritating. Perhaps we need several levels:
Error, Warning, Style Critique, Friendly Advice, Kibitz.
-- Scott
∂01-Nov-85 1242 shebs%utah-orion@utah-cs.arpa Declaring Functions
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 12:41:22 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA20713; Fri, 1 Nov 85 13:45:59 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA07112; Fri, 1 Nov 85 13:45:55 MST
Date: Fri, 1 Nov 85 13:45:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8511012045.AA07112@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Declaring Functions
The notion of a function type is mentioned in two places: p. 47 of the
CLM, where the (function ...) type specifier is defined, and p. 158-159,
where (ftype ...) and (function ...) are defined as options to declare.
Are they intended to be the same? If so, then the second definition
should say that keywords and a (values ...) type specifier are allowed.
If not, then what is the point of a function type specifier, since you
can't feed it to typep anyway?
Also, what is the intended syntax for lambda lists with keywords in
a type specifier? Somehow,
(deftype make-seq-type ()
'(function (type integer &key initial-element t) sequence))
doesn't look quite right... Has anybody done anything but punt on
function declarations?
stan shebs
∂01-Nov-85 1529 DCP@SCRC-STONY-BROOK.ARPA free variable references in interpreter.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 15:29:19 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 346455; Fri 1-Nov-85 17:57:03-EST
Date: Fri, 1 Nov 85 17:59 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: free variable references in interpreter.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Guy Steele <gls@AQUINAS.THINK.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12155831623.BABYL@C.CS.CMU.EDU>
Message-ID: <851101175928.6.DCP@NEPONSET.SCRC.Symbolics.COM>
Talking about supersets...
It seems obvious that supersets can extend functions by allowing more
optional arguments or additional keywords to those already specified in
CLtL. For example, Symbolics' make-array can take a
:displaced-conformally keyword to do multidimensional displacement in a
slightly different way than specified.
That's all well and good for the function calling direction, but what
about the receiving direction? That is, we have had requests to have
GETHASH return three values instead of two, the third being the key as
stored in the hash table, which might be EQUAL but not EQ to the given
to GETHASH. This third value seems OK since most applications will only
be looking for one or two values. But what about subtle cases like
(multiple-value-list (gethash key hash-table))
or
(multiple-value-call #'list
(gethash key1 hash-table)
(gethash key2 hash-table))
where the difference is readily apparent.
Therefore, I have two questions:
Do we all agree that extra optional arguments or additional keyword
arguments are an upward compatible extension and that programs that do
not use these extensions should run on other implementations?
What about the extra values problem? Note that CLtL does not have a way
to say I want <n> values as a result of executing this form. Again,
programs that do not use the extra values will run on all
implementations, except for those places (such as the above examples)
where the extra values are visible.
∂01-Nov-85 1721 FAHLMAN@C.CS.CMU.EDU free variable references in interpreter.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Nov 85 17:21:28 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 Nov 85 20:22:41-EST
Date: Fri, 1 Nov 1985 20:22 EST
Message-ID: <FAHLMAN.12155894458.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: free variable references in interpreter.
In-reply-to: Msg of 1 Nov 1985 17:59-EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
I think that it is OK for an implementation to take extra args and
keywords on the built-in functions. I can't think of any reasonable
ways in which this breaks correct Common Lisp programs, though it might
make trouble if the Common Lisp standard is later extended to allow
additional arguments that are not the same as the ones this
implementation has chosen.
I think that extra multiple values are another thing that ought to be
legal, but unfortunately there are ways in which these would break
certain legal but odd programs, as you point out. I think we blew the
language design here -- we just weren't thinking of this issue when we
nailed down the multiple-value stuff.
So, I suppose that in order to be 100% legal, an implementation should
not return extra values, unless perhaps they can be turned off with a
switch. As deviations go, however, this is a pretty harmless class of
them, breaking only rather odd code. So if there is a really good
reason to return extra values as an extension, it might be reasonable to
go ahead and do this, as long as this minor deviation from the standard
is carefully documented as such.
-- Scott
∂02-Nov-85 2052 isrlist@tove.umd.edu defvar, defparameter, :unbound
Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 2 Nov 85 20:52:38 PST
Received: by tove.umd.edu (5.5/4.7)
id AA00775; Sat, 2 Nov 85 23:55:45 EST
Date: Sat, 2 Nov 85 23:55:45 EST
Message-Id: <8511030455.AA00775@tove.umd.edu>
From: Nick Papadakis <isrlist@tove.umd.edu>
To: common-lisp@su-ai.ARPA
Subject: defvar, defparameter, :unbound
On the lispmachines, defvar will take a second argument of :unbound,
meaning that the variable will be initialized to an unbound state.
This occaisionally convenient feature should probably be added to
common-lisp, and defparameter should be extended to handle it as well.
- nic
∂03-Nov-85 0510 GJC@MIT-MC.ARPA extra features/values
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85 05:10:40 PST
Date: Sun, 3 Nov 85 08:12:39 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: extra features/values
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU,
gls@AQUINAS.THINK.COM
In-reply-to: Msg of Fri 1 Nov 85 17:59 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].703111.851103.GJC>
How about (gethash key hash-table :give-me-extra-stuff t).
∂03-Nov-85 0719 SOLEY@MIT-MC.ARPA defvar, defparameter, :unbound
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85 07:19:17 PST
Date: Sun, 3 Nov 85 10:21:19 EST
From: Richard Mark Soley <SOLEY@MIT-MC.ARPA>
Subject: defvar, defparameter, :unbound
To: isrlist@TOVE.UMD.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Sat 2 Nov 85 23:55:45 EST from Nick Papadakis <isrlist at tove.umd.edu>
Message-ID: <[MIT-MC.ARPA].703165.851103.SOLEY>
Date: Sat, 2 Nov 85 23:55:45 EST
From: Nick Papadakis <isrlist at tove.umd.edu>
To: common-lisp at su-ai.ARPA
Re: defvar, defparameter, :unbound
On the lispmachines, defvar will take a second argument of :unbound,
meaning that the variable will be initialized to an unbound state.
This occaisionally convenient feature should probably be added to
common-lisp, and defparameter should be extended to handle it as well.
I disagree. (defvar foo :unbound), to me, reads "set the value of the
symbol 'foo' to the symbol 'unbound' in the keyword package. I think
(defvar foo) is more readable.
-- Richard
∂03-Nov-85 0724 SOLEY@MIT-MC.ARPA extra features/values
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85 07:24:06 PST
Date: Sun, 3 Nov 85 10:26:06 EST
From: Richard Mark Soley <SOLEY@MIT-MC.ARPA>
Subject: extra features/values
To: GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU,
gls@AQUINAS.THINK.COM, DCP@SCRC-QUABBIN.ARPA
In-reply-to: Msg of Sun 3 Nov 85 08:12:39 EST from George J. Carrette <GJC at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].703168.851103.SOLEY>
Date: Sun, 3 Nov 85 08:12:39 EST
From: George J. Carrette <GJC at MIT-MC.ARPA>
To: DCP at SCRC-QUABBIN.ARPA
cc: common-lisp at SU-AI.ARPA, Fahlman at C.CS.CMU.EDU,
gls at AQUINAS.THINK.COM
Re: extra features/values
How about (gethash key hash-table :give-me-extra-stuff t).
This solves the GETHASH problem, but not the general problem (there are
likely to be many more functions from which a particular implementation wants
to return more values). And I don't think adding the :give-me-extra-stuff
keyword to every one of them helps. I think the one, central,
*ARE-WE-IN-PURE-COMMON-LISP-YET?* switch should control extra return value
behavior, to help the poor user who codes
(nth 2 (append (multiple-value-list (gethash key1 hasht1))
(multiple-value-list (gethash key2 hasht2)))
-- Richard
∂04-Nov-85 0846 DCP@SCRC-QUABBIN.ARPA free variable references in interpreter.
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 08:44:12 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 217507; Mon 4-Nov-85 11:45:30-EST
Date: Mon, 4 Nov 85 11:49 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: free variable references in interpreter.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
George J. Carrette <GJC@MIT-MC.ARPA>,
Richard Mark Soley <SOLEY@MIT-MC.ARPA>,
David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-Reply-To: <FAHLMAN.12155894458.BABYL@C.CS.CMU.EDU>,
<[MIT-MC.ARPA].703111.851103.GJC>,
<[MIT-MC.ARPA].703168.851103.SOLEY>
Message-ID: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM>
I disagree with what GJC said, because of the reasons Soley gave, but I
disagree with Soley's counter on aesthetic reasons. Suppose there were
a magic switch. What would the end of GETHASH look like?
(return-from gethash
(if *pure-cl*
(values entry got-it-p)
(values entry got-it-p key-stored-in-hash-table)))
That doesn't appeal to me, and neither does
(multiple-value-call #'values
(values entry got-it-p)
(if *pure-cl* (values) (values key-stored-in-hash-table)))
I suppose this could be packaged as macros, but then I ask you: is it
reasonable for people to have to bind *pure-cl* to NIL (presumably it
has to default to to) in order to get extra values? How is this really
different from GJC's request-is-via-optional-arguments-on-the-call-side?
A couple more random points of information. I think multiple-value-call
is a poor name. It should be called multiple-value-funcall. The
symbolics system has a special form called sys:%multiple-value-call-n
which looks like
(sys:%multiple-value-call-n fun vals1 n1 vals2 n2 ...)
which is more-or-less a highly optimized
(multiple-value-call #'fun
(multiple-value-bind (v1 v2 ... vn1)
vals1
(values v1 v2 ... vn1))
(multiple-value-bind (v1 v2 ... vn2)
vals2
(values v1 v2 ... vn2))
...)
In other words, fun is unquoted (for esoterit historical reasons I can
never remember), and the pairs of values-count say effectively "evaluate
valsM for nM values." This win about this special form is that it is
insensitive to extra values because the caller explicitly says how many
values are requested.
∂04-Nov-85 1022 @MIT-MC.ARPA:Soley@MIT-MC.ARPA free variable references in interpreter.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 10:21:55 PST
Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 NOV 85 13:23:14 EST
Date: Mon, 4 Nov 85 13:23 EST
From: Soley@MIT-MC.ARPA
Subject: free variable references in interpreter.
To: DCP@SCRC-QUABBIN.ARPA, Fahlman@C.CS.CMU.EDU, GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-Reply-To: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <851104132305.1.SOLEY@CHERRY.MIT.EDU>
Date: Mon, 4 Nov 85 11:49 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: free variable references in interpreter.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
George J. Carrette <GJC@MIT-MC.ARPA>,
Richard Mark Soley <SOLEY@MIT-MC.ARPA>,
David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
I disagree with what GJC said, because of the reasons Soley gave, but I
disagree with Soley's counter on aesthetic reasons. Suppose there were
a magic switch. What would the end of GETHASH look like?
(return-from gethash
(if *pure-cl*
(values entry got-it-p)
(values entry got-it-p key-stored-in-hash-table)))
That doesn't appeal to me.
Meta-point: I don't think we should care whether the IMPLEMENTATION code
is appealing or not, but whether code written in Common Lisp itself is
appealing. I think the form above is fine.
I think that the usual way such a switch would be used would be used
would be one of:
(1) Some macro, like (IN-LOCAL-CL-DIALECT-SUPERSET (gethash . . .))
(2) "-*- Dialect: Symbolics-Common-Lisp -*-" in the file's attribute
list.
(3) A global proclamation: (PROCLAIM '(SUPER-WINNING-LOCAL-DIALECT T)).
-- Richard
∂04-Nov-85 1022 @MIT-MC.ARPA:Soley@MIT-MC.ARPA free variable references in interpreter.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 10:22:24 PST
Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 NOV 85 13:23:37 EST
Date: Mon, 4 Nov 85 13:23 EST
From: Soley@MIT-MC.ARPA
Subject: free variable references in interpreter.
To: DCP@SCRC-QUABBIN.ARPA, Fahlman@C.CS.CMU.EDU, GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-Reply-To: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <851104132305.1.SOLEY@CHERRY.MIT.EDU>
Date: Mon, 4 Nov 85 11:49 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: free variable references in interpreter.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
George J. Carrette <GJC@MIT-MC.ARPA>,
Richard Mark Soley <SOLEY@MIT-MC.ARPA>,
David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
I disagree with what GJC said, because of the reasons Soley gave, but I
disagree with Soley's counter on aesthetic reasons. Suppose there were
a magic switch. What would the end of GETHASH look like?
(return-from gethash
(if *pure-cl*
(values entry got-it-p)
(values entry got-it-p key-stored-in-hash-table)))
That doesn't appeal to me.
Meta-point: I don't think we should care whether the IMPLEMENTATION code
is appealing or not, but whether code written in Common Lisp itself is
appealing. I think the form above is fine.
I think that the usual way such a switch would be used would be used
would be one of:
(1) Some macro, like (IN-LOCAL-CL-DIALECT-SUPERSET (gethash . . .))
(2) "-*- Dialect: Symbolics-Common-Lisp -*-" in the file's attribute
list.
(3) A global proclamation: (PROCLAIM '(SUPER-WINNING-LOCAL-DIALECT T)).
-- Richard
∂04-Nov-85 1240 DLW@SCRC-STONY-BROOK.ARPA defvar, defparameter, :unbound
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 12:40:00 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347463; Mon 4-Nov-85 15:41:20-EST
Date: Mon, 4 Nov 85 15:44 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: defvar, defparameter, :unbound
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8511030455.AA00775@tove.umd.edu>
Message-ID: <851104154406.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sat, 2 Nov 85 23:55:45 EST
From: Nick Papadakis <isrlist@tove.umd.edu>
On the lispmachines, defvar will take a second argument of :unbound,
meaning that the variable will be initialized to an unbound state.
I'm not sure which Lisp machine this message is supposed to apply to,
but just for the record, the Symbolics system does not do this.
∂04-Nov-85 1447 AS%hp-hulk.csnet@CSNET-RELAY.ARPA functions that return nonstandard extra values
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 14:47:25 PST
Received: from hplabs by csnet-relay.csnet id ab03268; 4 Nov 85 17:50 EST
Received: by HP-VENUS id AA02886; Mon, 4 Nov 85 09:44:50 pst
Message-Id: <8511041744.AA02886@HP-VENUS>
Date: Mon 4 Nov 85 09:43:53-PST
From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Subject: functions that return nonstandard extra values
To: common-lisp@su-ai.arpa
Source-Info: From (or Sender) name not authenticated.
Why not use the traditional solution of giving these
nonstandard functions different names? Then you don't
have to worry about them becoming incompatible should
the standard be extended to have more return values.
-------
∂04-Nov-85 1500 hplabs!perdue%hplabs.csnet@CSNET-RELAY.ARPA Re: free variable references in interpreter.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 15:00:16 PST
Received: from hplabs by csnet-relay.csnet id af03268; 4 Nov 85 17:56 EST
Received: by HP-VENUS id AA10185; Mon, 4 Nov 85 14:24:06 pst
Message-Id: <8511042224.AA10185@HP-VENUS>
Date: Monday, November 4, 1985 14:21:50
From: perdue%hplabs.csnet@CSNET-RELAY.ARPA
Subject: Re: free variable references in interpreter.
To: common-lisp@su-ai.arpa
In-Reply-To: Your message of 1-Nov-85 14:37:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info: From (or Sender) name not authenticated.
Scott Fahlman's comments on permissibility of warning and error
messages when not called for by the Common LISP definition
look good to me.
Portably written code should port without hassles, and drawing
the line between warnings and errors looks right. Warning
messages for legal code are OK sometimes as default behavior,
but signalling errors is not.
-------
∂04-Nov-85 1703 DCP@SCRC-STONY-BROOK.ARPA functions that return nonstandard extra values
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 16:19:43 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347618; Mon 4-Nov-85 19:22:09-EST
Date: Mon, 4 Nov 85 19:25 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: functions that return nonstandard extra values
To: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>,
common-lisp@SU-AI.ARPA
In-Reply-To: <8511041744.AA02886@HP-VENUS>
Message-ID: <851104192526.3.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon 4 Nov 85 09:43:53-PST
From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Why not use the traditional solution of giving these
nonstandard functions different names? Then you don't
have to worry about them becoming incompatible should
the standard be extended to have more return values.
Because code that does a GETHASH but wants an extra value will have a
wart called GETHASH-MAGIC (or whatever, but not GETHASH), which could
conceivably double the number of functions in the superset. If CL
changes, and it does so slowly because it is a standard, extensions are
expected to become compatible with the new standard and applications
that used the old extensions must be modified. Note they would have to
be modified anyway in order to take advantage of the change to CL.
∂04-Nov-85 1858 GJC@MIT-MC.ARPA functions that return nonstandard extra values
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 18:58:47 PST
Date: Mon, 4 Nov 85 22:00:48 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: functions that return nonstandard extra values
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-reply-to: Msg of Mon 4 Nov 85 19:25 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].705135.851104.GJC>
On the bright side, the existence of a standard helps system maintainers
to resist users continually asking for changes to the language that
have but minor benefit, such as this gethash thing. With only
a minor change in efficiency the user could store (CONS <key> <value>)
in the hash table, and get what he wanted, the EQ'ified key and
the value. If a user was really interested in efficiency he wouldnt
use the hairy system-provided hash table implementations anyway.
∂04-Nov-85 1925 DLW@SCRC-STONY-BROOK.ARPA Declaring Functions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 19:23:48 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347679; Mon 4-Nov-85 22:26:17-EST
Date: Mon, 4 Nov 85 22:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Declaring Functions
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8511012045.AA07112@utah-orion.ARPA>
Message-ID: <851104222904.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 1 Nov 85 13:45:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
The notion of a function type is mentioned in two places: p. 47 of the
CLM, where the (function ...) type specifier is defined, and p. 158-159,
where (ftype ...) and (function ...) are defined as options to declare.
Are they intended to be the same?
Read page 159 more carefully. It explains that they have the same
meaning, but are syntactically different. "function" has the
disadvantage that you can only declare one thing per clause, unlike most
other declarations, but the advantage that it looks mildly like "defun".
If so, then the second definition
should say that keywords and a (values ...) type specifier are allowed.
If by keywords you mean &optional and friends, it isn't strictly
necessary to repeat that, although it would sure clear things up if
there were a cross reference in the book.
However, there appears to be a typo on page 159. The form following the
phrase "entirely equivalent to", which currently reads
(ftype (function arglist result-type1 result-type2 ...) name)
ought to read
(ftype (function arglist (values result-type1 result-type2 ...)) name)
in order to be consistent with page 47.
∂04-Nov-85 1934 DLW@SCRC-STONY-BROOK.ARPA functions that return nonstandard extra values
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 19:34:06 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347683; Mon 4-Nov-85 22:33:07-EST
Date: Mon, 4 Nov 85 22:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: functions that return nonstandard extra values
To: GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[MIT-MC.ARPA].705135.851104.GJC>
Message-ID: <851104223554.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 4 Nov 85 22:00:48 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
If a user was really interested in efficiency he wouldnt
use the hairy system-provided hash table implementations anyway.
This is completely the opposite of our point of view, which is that it
is the job of the system to provide usable and efficient tools.
∂04-Nov-85 2019 GSB@MIT-MC.ARPA defvar, defparameter, :unbound
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 20:16:59 PST
Date: Mon, 4 Nov 85 23:18:59 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
Subject: defvar, defparameter, :unbound
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].705297.851104.GSB>
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Sat, 2 Nov 85 23:55:45 EST
From: Nick Papadakis <isrlist@tove.umd.edu>
On the lispmachines, defvar will take a second argument of :unbound,
meaning that the variable will be initialized to an unbound state.
I'm not sure which Lisp machine this message is supposed to apply to,
but just for the record, the Symbolics system does not do this.
This hack was added to NIL. My personal feeling is that the special
case value is just asking to screw some poor user whose code just
happens to naively use :UNBOUND to mean something... But i added the
defvar hack anyway, because the ability to do both the defvar and
specify the documentations string in a single form seemed worth it.
Doing
(defvar *foo*)
(setf (documentation '*foo* 'variable) "Documentaiton string")
looks pretty crufty. Keyworded defvar, anyone?
∂05-Nov-85 0734 DCP@SCRC-STONY-BROOK.ARPA functions that return nonstandard extra values
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 07:34:06 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347879; Tue 5-Nov-85 10:31:04-EST
Date: Tue, 5 Nov 85 10:34 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: functions that return nonstandard extra values
To: George J. Carrette <GJC@MIT-MC.ARPA>, DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[MIT-MC.ARPA].705135.851104.GJC>
Message-ID: <851105103431.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 4 Nov 85 22:00:48 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
On the bright side, the existence of a standard helps system maintainers
to resist users continually asking for changes to the language that
have but minor benefit, such as this gethash thing. With only
a minor change in efficiency the user could store (CONS <key> <value>)
in the hash table, and get what he wanted, the EQ'ified key and
the value.
This is no longer a simple hash table, as GETHASH doesn't get the value.
Instead, the user must do (CDR (GETHASH ...)), and MUST do it in all
places. There are other problems with this solution. PUTHASH over an
existing entry will change the key, forcing the user to do a GETHASH
first. This is almost MODIFY-HASH, which is an efficiency item missing
from CL.
If a user was really interested in efficiency he wouldnt
use the hairy system-provided hash table implementations anyway.
I agree with DLW's reply to this statement.
∂05-Nov-85 0941 gls@THINK-AQUINAS.ARPA functions that return nonstandard extra values
Received: from THINK.COM by SU-AI.ARPA with TCP; 5 Nov 85 09:41:06 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 5 Nov 85 12:41:19 est
Date: Tue, 5 Nov 85 12:42 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: functions that return nonstandard extra values
To: DLW@SCRC-QUABBIN.ARPA, GJC@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA,
gls@THINK-AQUINAS.ARPA
In-Reply-To: <851104223554.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851105124241.2.GLS@DESIDERIUS.THINK.COM>
Date: Mon, 4 Nov 85 22:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Mon, 4 Nov 85 22:00:48 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
If a user was really interested in efficiency he wouldnt
use the hairy system-provided hash table implementations anyway.
This is completely the opposite of our point of view, which is that it
is the job of the system to provide usable and efficient tools.
My feeling exactly. If implementations are such that users find it
desirable to ignore most of the built-in functions and roll their own,
then we have failed: we might as well have used a smaller dialect, such
as SCHEME or PSL. Common Lisp took the direction it did precisely
because we thought that all the built-in functions would be useful to
users.
--Guy
∂05-Nov-85 0950 gls@THINK-AQUINAS.ARPA defvar, defparameter, :unbound
Received: from THINK.COM by SU-AI.ARPA with TCP; 5 Nov 85 09:49:47 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 5 Nov 85 12:51:56 est
Date: Tue, 5 Nov 85 12:53 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: defvar, defparameter, :unbound
To: GSB@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <[MIT-MC.ARPA].705297.851104.GSB>
Message-Id: <851105125319.3.GLS@DESIDERIUS.THINK.COM>
Date: Mon, 4 Nov 85 23:18:59 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Sat, 2 Nov 85 23:55:45 EST
From: Nick Papadakis <isrlist@tove.umd.edu>
On the lispmachines, defvar will take a second argument of :unbound,
meaning that the variable will be initialized to an unbound state.
I'm not sure which Lisp machine this message is supposed to apply to,
but just for the record, the Symbolics system does not do this.
This hack was added to NIL. My personal feeling is that the special
case value is just asking to screw some poor user whose code just
happens to naively use :UNBOUND to mean something... But i added the
defvar hack anyway, because the ability to do both the defvar and
specify the documentations string in a single form seemed worth it.
Doing
(defvar *foo*)
(setf (documentation '*foo* 'variable) "Documentaiton string")
looks pretty crufty. Keyworded defvar, anyone?
One idea that was discussed previously was
(defvar *foo* *foo* "Documentation string")
which self-evidently means "declare *foo* and initialize to its existing
value", but by special dispensation it arranges to work even when *foo*
is already unbound, i.e., it leaves it alone. This is fine for DEFVAR,
but is less appealing for DEFPARAMETER.
--Guy
∂05-Nov-85 1154 isrlist@tove.umd.edu defvar, defparameter, :unbound
Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 5 Nov 85 11:54:25 PST
Received: by tove.umd.edu (5.5/4.7)
id AA01113; Tue, 5 Nov 85 12:36:00 EST
Date: Tue, 5 Nov 85 12:36:00 EST
Message-Id: <8511051736.AA01113@tove.umd.edu>
From: Nick Papadakis <isrlist@tove.umd.edu>
To: SOLEY@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: Richard Mark Soley's message of Sun, 3 Nov 85 10:21:19 EST
Subject: defvar, defparameter, :unbound
I disagree. (defvar foo :unbound), to me, reads "set the value of the
symbol 'foo' to the symbol 'unbound' in the keyword package. I think
(defvar foo) is more readable.
-- Richard
What if you want to use the optional documentation argument, as in
(defvar foo :unbound "I am initially unbound.") ???
How can you document it and yet leave it unbound too?
The problem initially arose when re-writing some code that made heavy
use of
(unless (boundp 'foo) ...
as a means of insuring that variables were initialized. The variables
were NOT initialized in the defvar itself since re-initialization was
frequent and interactive.
- nic
∂05-Nov-85 1213 LOOSEMORE@UTAH-20.ARPA queries about *query-io*
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 12:13:52 PST
Date: Tue 5 Nov 85 13:16:24-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: queries about *query-io*
To: common-lisp@SU-AI.ARPA
Message-ID: <12156887294.22.LOOSEMORE@UTAH-20.ARPA>
What should *query-io* be bound to when running Lisp in "batch mode" where
normal input comes from a script file and there is not necessarily a
terminal or interactive process associated with the Lisp process? For the
purposes of y-or-n-p, it might be reasonable to bind *query-io* to the
script file, since these are questions expected by the user and the answers
could be included in the script file. However, for unexpected questions
asked via yes-or-no-p, this approach would almost certainly fail. Or,
*query-io* could be left unbound or it could be bound to an empty stream.
This leads to the second problem: what should y-or-n-p and yes-or-no-p
do if *query-io* is unbound or has an end-of-file condition? Since there
is no way to specify a default value to be returned, I think signalling an
error is about the only reasonable thing to do. Comments?
-Sandra Loosemore
-------
∂05-Nov-85 1239 DCP@SCRC-STONY-BROOK.ARPA defvar, defparameter, :unbound
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 12:38:57 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 348169; Tue 5-Nov-85 15:41:25-EST
Date: Tue, 5 Nov 85 15:44 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: defvar, defparameter, :unbound
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, GSB@MIT-MC.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: <851105125319.3.GLS@DESIDERIUS.THINK.COM>
Message-ID: <851105154455.3.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Tue, 5 Nov 85 12:53 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Mon, 4 Nov 85 23:18:59 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Sat, 2 Nov 85 23:55:45 EST
From: Nick Papadakis <isrlist@tove.umd.edu>
On the lispmachines, defvar will take a second argument of :unbound,
meaning that the variable will be initialized to an unbound state.
I'm not sure which Lisp machine this message is supposed to apply to,
but just for the record, the Symbolics system does not do this.
This hack was added to NIL. My personal feeling is that the special
case value is just asking to screw some poor user whose code just
happens to naively use :UNBOUND to mean something... But i added the
defvar hack anyway, because the ability to do both the defvar and
specify the documentations string in a single form seemed worth it.
Doing
(defvar *foo*)
(setf (documentation '*foo* 'variable) "Documentaiton string")
looks pretty crufty. Keyworded defvar, anyone?
One idea that was discussed previously was
(defvar *foo* *foo* "Documentation string")
which self-evidently means "declare *foo* and initialize to its existing
value", but by special dispensation it arranges to work even when *foo*
is already unbound, i.e., it leaves it alone. This is fine for DEFVAR,
but is less appealing for DEFPARAMETER.
Recall that DEFPARAMETER's initial value is not optional, with implied
(perhaps stated) semantics that it must always have a value.
∂05-Nov-85 1517 HENRIK@MIT-MC.ARPA queries about *query-io*
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 15:15:27 PST
Date: Tue, 5 Nov 85 18:17:28 EST
From: "Lawrence A. DeLuca, Jr." <HENRIK@MIT-MC.ARPA>
Subject: queries about *query-io*
To: LOOSEMORE@UTAH-20.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].706637.851105.HENRIK>
I guess the closest analogy to "batch mode" the lisp machine offers is
a deexposed window with a process running in it. In this case, when
a process wants to type out or needs input the user is sent a message
that the window requires attention, a la:
Process SUPDUP1 Wants to type out.
The process can continue to output, and the text will be displayed the
next time the user exposes the window. When typein is required, the
process will wait until the required input is supplied. It would
probably be most reasonable to have the output of *query-io* go to
*standard-output*.
As to the question of (y-or-n-p ... ), most batch processes are only
going to use some such construct to signal an unusual event, so it
would probably be better to have the process wait for input (assuming
there is some method to "attach" to the process provided) as opposed
to merely signaling and error and returning, or worse, aborting.
larry...
∂05-Nov-85 1655 LOOSEMORE@UTAH-20.ARPA Re: queries about *query-io*
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 16:55:29 PST
Date: Tue 5 Nov 85 17:57:57-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: queries about *query-io*
To: HENRIK@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].706637.851105.HENRIK>
Message-ID: <12156938550.9.LOOSEMORE@UTAH-20.ARPA>
I'm afraid this approach would not work very well in a multi-user
environment. In VMS, for example, the user can submit a job to a batch
queue and then log off the interactive terminal and go away for a week. It
would not be looked upon very kindly by other users to have this batch job
sitting indefinitely waiting for the user to log back on again so it can
ask him/her a question, and all the while consuming cpu time and clogging up
the batch queue. And the problem is not unique to VMS -- one can do similar
things under Unix and probably other operating systems as well.
-Sandra
-------
∂06-Nov-85 0400 GJC@MIT-MC.ARPA (GETHASH X Y) ==> (CDR (GETHASH X Y))
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 04:00:19 PST
Date: Wed, 6 Nov 85 07:02:23 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: (GETHASH X Y) ==> (CDR (GETHASH X Y))
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-reply-to: Msg of Tue 5 Nov 85 10:34 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].707437.851106.GJC>
It is ridiculous to assume that users program via QUERY-REPLACE in EMACS,
or through the "looks productive" CONTROL-K CONTROL-Y method.
More likely it is the case that:
(DEFUN DATABASE-LOOKUP (...)
(GETHASH ...) ... (PUTHASH ....))
For one thing the user might consider GETHASH to be a silly name.
∂06-Nov-85 0429 GJC@MIT-MC.ARPA functions that return nonstandard extra values
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 04:27:25 PST
Date: Wed, 6 Nov 85 07:29:27 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: functions that return nonstandard extra values
To: DLW@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-reply-to: Msg of Mon 4 Nov 85 22:35 EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].707467.851106.GJC>
Date: Mon, 4 Nov 85 22:35 EST
From: Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
To: GJC at MIT-MC.ARPA
cc: common-lisp at SU-AI.ARPA, AS%hplabs.csnet at CSNET-RELAY.ARPA
Re: functions that return nonstandard extra values
Date: Mon, 4 Nov 85 22:00:48 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
If a user was really interested in efficiency he wouldnt
use the hairy system-provided hash table implementations anyway.
This is completely the opposite of our point of view, which is that it
is the job of the system to provide usable and efficient tools.
Oh, I love your use of the royal WE/OUR here. Lets not make this into
a OUR-COMPANY (RA RA!!!) vs others kind of thing. I'm talking
about what lispmachine systems provide NOW. Remember how long it
took the lispmachine crew to adopt semantically correct SETF, long
after other implementations had done so. The track record is not good.
In fact, the track record is one of unabated changes that continously
break major applications packages in minor ways, diverting resources,
and all in the name of progress. (RA RA).
If your soapbox stand is that it is my(i.e. LMI's) view that
the system does not have to provide usable and efficient tools then
a retraction of your statement is in order.
But the Common-Lisp system lacks many useful basic tools. Functions for
manipulating circular queues, or recursive alists (like TRI's), or
resolution nets. It lacks a DEFSTRUCT that can deal with
the same kind of data that STRUCT in C deals with. (Disk Controller blocks,
Filesystem records, network packets defined by programmers in the non-lisp
world, etc). There are many things a user will have to build himself.
∂06-Nov-85 0738 MEEHAN@YALE.ARPA CL erratissimo
Received: from YALE.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 07:37:52 PST
Received: by Yale-Bulldog.YALE.ARPA; 6 Nov 85 10:30:50 EST (Wed)
Message-Id: <8511061530.AA07724@Yale-Bulldog.YALE.ARPA>
Date: Wed, 6 Nov 85 10:33:11 EST
From: Jim Meehan <Meehan@YALE.ARPA>
Subject: CL erratissimo
To: common-lisp@SU-AI
Section 7.9.2, Rules Governing the Passing of Multiple Values, is indexed
under "multiple values," sub-indexed under "rules governing parsing of."
↑
(Not exactly your random typo.)
-------
∂06-Nov-85 0904 mips!escargot.earl@glacier defvar, defparameter, :unbound
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 09:04:12 PST
Received: by glacier with Sendmail; Wed, 6 Nov 85 09:05:50 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
id AA14102; Wed, 6 Nov 85 07:03:44 pst
Received: by escargot.UUCP (4.12/4.7)
id AA06129; Wed, 6 Nov 85 07:02:16 pst
Date: Wed, 6 Nov 85 07:02:16 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8511061502.AA06129@escargot.UUCP>
To: Glacier!isrlist@tove.umd.edu
Cc: SOLEY@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Nick Papadakis's message of Tue, 5 Nov 85 12:36:00 EST
Subject: defvar, defparameter, :unbound
This doesn't seem important enough to become a language feature; one
of advantages of lisp is that you could have written a DOCVAR macro
that does what you want for this one particular application, and then
just done
(docvar foo "Foo is unbound")
instead of
(defvar foo :unbound "Foo is unbound")
∂06-Nov-85 0947 gls@THINK-AQUINAS.ARPA CL erratissimo
Received: from THINK.COM by SU-AI.ARPA with TCP; 6 Nov 85 09:47:35 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 6 Nov 85 12:49:40 est
Date: Wed, 6 Nov 85 12:51 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: CL erratissimo
To: Meehan@YALE.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8511061530.AA07724@Yale-Bulldog.YALE.ARPA>
Message-Id: <851106125102.4.GLS@DESIDERIUS.THINK.COM>
Date: Wed, 6 Nov 85 10:33:11 EST
From: Jim Meehan <Meehan@YALE.ARPA>
Section 7.9.2, Rules Governing the Passing of Multiple Values, is indexed
under "multiple values," sub-indexed under "rules governing parsing of."
↑
(Not exactly your random typo.)
-------
Snows me. Good eye!
--Guy
∂08-Nov-85 1646 FAHLMAN@C.CS.CMU.EDU astronaut example on p.313
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Nov 85 16:46:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 8 Nov 85 19:18:25-EST
Date: Thu, 7 Nov 1985 22:10 EST
Message-ID: <FAHLMAN.12157486962.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: astronaut example on p.313
In-reply-to: Msg of 7 Nov 1985 14:56-EST from S Sridhar <sridhar%tekchips%tektronix.csnet at CSNET-RELAY.ARPA>
On p.313, we've
(setq x (make-astronaut :name 'buzz :age 45
:sex t :helmet-size 17.5))
I don't like this :sex t. It would be perhaps more appropriate
to have :sex 'm or :sex 'f or ...
--sridhar
A deliberate joke on Guy's part, I believe. A more amusing value might
be 7.3, however...
-- Scott
∂08-Nov-85 1648 FAHLMAN@C.CS.CMU.EDU Language spec should be public domain
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Nov 85 16:46:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 8 Nov 85 19:18:24-EST
Date: Thu, 7 Nov 1985 22:06 EST
Message-ID: <FAHLMAN.12157486280.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: REM@MIT-MC.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Language spec should be public domain
In-reply-to: Msg of 1985 Nov 07 15:27:32 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
Before CL can ever become very widely used (like ASCII for example),
it must become an ANSI/CCITT/ISO standard...
I disagree totally with this view. Lots of things are widely used that
are not blessed by these particular bureaucracies. But I do agree with
the view that the proprietary nature of the document is hurting us, and
is hurting some more than others.
-- Scott
∂08-Nov-85 1649 gls@THINK-AQUINAS.ARPA Common Lisp manual online?
Received: from THINK.COM by SU-AI.ARPA with TCP; 8 Nov 85 16:49:31 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 8 Nov 85 14:37:01 est
Date: Fri, 8 Nov 85 14:38 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Common Lisp manual online?
To: Fahlman@C.CS.CMU.EDU, Masinter.pa@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12157444377.BABYL@C.CS.CMU.EDU>
Message-Id: <851108143815.3.GLS@THINK-DESIDERIUS.ARPA>
I can report that Dr. Toru Ishida of Nippon Telephone and Telegraph
requested of Digital Press permission to acquire a machine-readable copy
of the manual for research purposes (research into developing an on-line
query system), and this permission was granted relatively quickly (a
month or so). So that's one precedent. It's not the same as a
precedent for making the manual available on-line for commercial use.
Maybe someone would like to help establish one promptly? The way
lawyers are, I can push all I want for a policy from a theoretical point
of view, but you won't get action until there is an actual instance for
them to chew on.
--Guy
∂08-Nov-85 1651 gls@THINK-AQUINAS.ARPA astronaut example on p.313
Received: from THINK.COM by SU-AI.ARPA with TCP; 8 Nov 85 16:50:17 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 8 Nov 85 14:16:28 est
Date: Fri, 8 Nov 85 14:17 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: astronaut example on p.313
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 7 Nov 85 14:56-EST from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <851108141743.2.GLS@THINK-DESIDERIUS.ARPA>
Date: Thursday, 7 Nov 85 11:56:33 PST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
On p.313, we've
(setq x (make-astronaut :name 'buzz :age 45
:sex t :helmet-size 17.5))
I don't like this :sex t. It would be perhaps more appropriate
to have :sex 'm or :sex 'f or ...
--sridhar
I suppose that this is one of the "subtly witty" things that Winston had
in mind (see the quote on the back cover). The entire point is that it
isn't clear. Then again it is: it says that the astronaut has a sex,
but doesn't say which. (HAL, in the movie 2001, is an examples of an
astronaut that has no sex.) I'm sorry you don't like it. It certainly
is not exemplary of god programming style. Maybe we should change it in
the next edition.
--Guy
∂08-Nov-85 1705 hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA compiler-let (clarification needed)
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 8 Nov 85 17:05:38 PST
Received: from hplabs by csnet-relay.csnet id ah07165; 8 Nov 85 8:25 EST
Received: by HP-VENUS id AA06577; Thu, 7 Nov 85 16:34:35 pst
Message-Id: <8511080034.AA06577@HP-VENUS>
Date: Thursday, November 7, 1985 08:41:25
From: snyder%hplabs.csnet@CSNET-RELAY.ARPA
Subject: compiler-let (clarification needed)
To: common-lisp@su-ai.arpa
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info: From (or Sender) name not authenticated.
The definition of COMPILER-LET (page 112) states that when executed by the
"Lisp interpreter", COMPILER-LET behaves exactly like LET (with all the
variable bindings implicitly declared SPECIAL). However, on page 143 it
states that a Common Lisp implementation might, for example, expand macros in
a DEFUN at the time the DEFUN is executed.
Since the primary purpose of COMPILER-LET is to provide for the communication
of information at macro expansion time, I believe that if an implementation
(even when "interpreting") expands macros before run-time, then it should
process a COMPILER-LET at that same time, in which case COMPILER-LET is NOT the
same as LET.
The definition of COMPILER-LET should be changed to make this clear.
Alan Snyder
-------
-------
∂08-Nov-85 2244 PGS%MIT-OZ@MIT-MC.ARPA astronaut example on p.313
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 Nov 85 22:43:57 PST
Date: Sat, 9 Nov 1985 01:47 EST
Message-ID: <PGS.12157788594.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: common-lisp@SU-AI.ARPA,
sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA
Subject: astronaut example on p.313
In-reply-to: Msg of 8 Nov 1985 14:17-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Date: Friday, 8 November 1985 14:17-EST
From: Guy Steele <gls at THINK-AQUINAS.ARPA>
Date: Thursday, 7 Nov 85 11:56:33 PST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
On p.313, we've
(setq x (make-astronaut :name 'buzz :age 45
:sex t :helmet-size 17.5))
I don't like this :sex t. It would be perhaps more appropriate
to have :sex 'm or :sex 'f or ...
I suppose that this is one of the "subtly witty" things that Winston had
in mind (see the quote on the back cover). The entire point is that it
isn't clear. Then again it is: it says that the astronaut has a sex,
but doesn't say which. (HAL, in the movie 2001, is an examples of an
astronaut that has no sex.) I'm sorry you don't like it. It certainly
is not exemplary of god programming style. Maybe we should change it in
the next edition.
Gee, I always read it as an allusion to the joke in which a job applicant,
filling out an employment application form, chews over the SEX: ←←←←
question for a while, and then writes in "Occasionally."
∂09-Nov-85 1115 DLW@SCRC-STONY-BROOK.ARPA Suggested addition to the index of CLtL
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Nov 85 11:13:45 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 351262; Sat 9-Nov-85 14:15:43-EST
Date: Sat, 9 Nov 85 14:20 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Suggested addition to the index of CLtL
To: common-lisp@SU-AI.ARPA
Message-ID: <851109142016.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
We've had several users who tried to figure out how to copy an array in
Common Lisp, and could not find a function in CLtL to do it. The
function is COPY-SEQ, but if you set off trying to find a function to
copy an array, you can miss it pretty easily. Perhaps an index entry
for "copying arrays" could be added to the index in the next edition, to
direct the programming to COPY-SEQ. ("Copying list", too, couldn't
hurt.) Thanks.
∂09-Nov-85 1606 RPG Meeting: The Details
To: common-lisp@SU-AI.ARPA
After much hassle and complaint, terror and theats; after a month
of ill-feelings and fights, I've scheduled the Common Lisp meeting
for specific days, at a specific place, and I am sending out the message
essentially 1 month ahead of time.
I know some of you will not like the details I have settled on.
The meeting will be Monday, Tuesday, Wednesday, Decembers 9, 10,
and 11; at:
Boston Marriott Hotel Copley Place
110 Huntington Avenue
Boston, Massachusetts 02117
(617)236-5800
The room will be ours from 8:30am until 6:00pm each of those days.
There is a block of rooms at that hotel set aside for us. I understand
that it is a fancy hotel, and the rooms are not cheap, even with
the discount I got for the meeting. The rooms are $100 single and
$115 double, which is $60 off the regular rate. When you make your
reservations, specifically mention the Common Lisp meeting.
The block of rooms will be held for us until November 25, and
they can be booked for the evenings of Decemeber 8, 9, 10.
The usual caveats apply to this hotel: a reservation without
a guarantee will only hold the room until 6:00pm of the evening
of your arrival. A guarantee is usually an American Express card
number.
The meeting room will hold 250 easily, but I understand that up to
350 could fit. The sessions will be sequential, not parallel.
There is a non-zero chance that DARPA will not be able to pay for the
meeting room; the hotel doesn't seem to want to give it to us free
if we fill up 75 rooms, which is unusual - they claim they need closer
to 200 filled by us to give us such a large meeting room. In the event
DARPA will not help us out, I will be approaching the vendors for contributions
towards the meeting room. For now, Lucid is fronting the money.
We can get coffee and pastry delivered to the meeting room in the mornings,
but it will also cost us. To do that would cost about $7.75 per person.
Is there an interest in this happening? If so, I will go ahead with the
arrangements, and perhaps you'll be dunned later.
The major topics as I see them are:
1. Charter
2. Adoption of changes discussed on this list
3. Plans for a second edition
4. Public Domain/Online manual
5. Object-oriented programming
6. Windows
7. Error Handling
8. Validation
I expect specific proposals to be discussed for topics 1, 5, 6, 7, and 8.
Vendors and implementation groups are allowed to send 2 voting individuals
(3 official repesentatives altogether), user groups are allowed to send 1
voting individual (2 official representatives altogether), and individuals
of standing in the community are allowed to attend and possibly vote.
Groups that are not implementing a Common Lisp, but who are proposing a
standard in some area which they intend to implement, are allowed to send
2 voting members for that session only.
Any one of Scott Fahlman, Guy Steele, or myself is allowed to grant
an individual standing in the community for the purposes of attending
the meeting as a voting individual.
I will allow into the room any observers up to a number which,
added to the voting and accessory repesentatives, leaves the room
comfortable. Thus, a vendor can send more than 3 people, but only
3 will be guaranteed spots in the room. In general, only the
official representatives and the qualified voting individuals will
be allowed to speak.
I hope we have a pleasant and productive meeting. See you all in
1 month.
-rpg-
Common-lisp/su
Reminder about the Common Lisp Meeting
I would like to remind you about the Common Lisp meeting, which will be
Monday, Tuesday, Wednesday, Decembers 9, 10, and 11; at:
Boston Marriott Hotel Copley Place
110 Huntington Avenue
Boston, Massachusetts 02117
(617)236-5800
The room will be ours from 8:30am until 6:00pm each of those days.
There is a block of rooms at that hotel set aside for us. I understand
that it is a fancy hotel, and the rooms are not cheap, even with
the discount I got for the meeting. The rooms are $100 single and
$115 double, which is $60 off the regular rate. When you make your
reservations, specifically mention the Common Lisp meeting.
Here is an important piece of information:
************************************************************************
* *
* The block of rooms will be held for us until November 25, and *
* they can be booked for the evenings of Decemeber 8, 9, 10. *
* *
************************************************************************
The usual caveats apply to this hotel: a reservation without
a guarantee will only hold the room until 6:00pm of the evening
of your arrival. A guarantee is usually an American Express card
number.
-rpg-
∂10-Nov-85 1828 EVAN@SU-CSLI.ARPA Pointers to vax/unix version
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 10 Nov 85 18:27:55 PST
Date: Sun 10 Nov 85 18:28:42-PST
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Pointers to vax/unix version
To: common-lisp@SU-AI.ARPA
I've been trying (unsuccessfully) for a while to track down a version
of Common Lisp (or even a reasonable subset) that runs under 4.2BSD
Unix. This is a very elusive animal, as everyone has heard rumours of
one, but nobody has every quite seen it. Any pointers anyone could
give would be most helpful and much appreciated.
Evan Kirshenbaum
ARPA: evan@SU-CSLI
UUCP: {ucbvax | decvax}!decwrl!glacier!evan
P.S. This is urgent. I'm doing a prototype using Hedrick's TOPS-20
version, and if you don't come through, they're going to make
me translate it into franz!!!
-------
∂11-Nov-85 0944 Kahn.pa@Xerox.ARPA RE: Steele's programming style
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 09:43:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 85 09:34:42 PST
Date: 11 Nov 85 09:34 PST
Sender: Kahn.pa@Xerox.ARPA
Subject: RE: Steele's programming style
To: COMMON-LISP@SU-AI.ARPA
From: bobrow.pa@Xerox.ARPA, kahn.pa@Xerox.ARPA
LineFold: No
Message-ID: <851111-093442-1201@Xerox>
I suppose that this is one of the "subtly witty" things that Winston had
in mind (see the quote on the back cover). The entire point is that it
isn't clear. Then again it is: it says that the astronaut has a sex,
but doesn't say which. (HAL, in the movie 2001, is an examples of an
astronaut that has no sex.) I'm sorry you don't like it. It certainly
is not exemplary of god programming style. Maybe we should change it in
the next edition.
--Guy
" not exemplary of god programming style "
We suppose god would never simply affirm sex,
but would be more explicit.
∂18-Nov-85 1331 gls@THINK-AQUINAS.ARPA TYPEP and arrays of (SATISFIES F)
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 18 Nov 85 13:31:02 PST
Received: from THINK-HILARION.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1220; Mon 18-Nov-85 16:35:19-EST
Date: Mon, 18 Nov 85 16:35 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: TYPEP and arrays of (SATISFIES F)
To: common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
Message-ID: <851118163500.9.GLS@THINK-HILARION.ARPA>
Bob Rorschach has raised the following question: what is the
result of (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10)))
supposed to be? Consider these special cases:
(TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE INTEGER)
'(ARRAY (SATISFIES FIXNUMP) (10)))
(TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE FIXNUM)
'(ARRAY (SATISFIES FIXNUMP) (10)))
We can easily dismiss the first case, because clearly an array
specialized to hold integers is not necessarily the same as one
specialized to hold fixnums. The second is more difficult. It happens
to be the case that FIXNUM and (SATISFIES FIXNUMP) are equivalent type
specifiers, but in many implementations SUBTYPEP cannot discern this
fact (and indeed is not required to).
When TYPEP sees a plain old SATISFIES specifier, it can just call the
function, but not so when it is the element type of an ARRAY specifier.
One way out (proposed language change) is to define TYPEP to be like
SUBTYPEP, in that it returns two values; if the first value is NIL, the
second value says whether that's a "no" or a "maybe". So for the
first special case above TYPE would return either NIL T or NIL NIL,
depending on the cleverness of the implementation, and for the second
special case would return either NIL NIL or T T.
--Guy
∂19-Nov-85 0056 RAM@C.CS.CMU.EDU :Structure-Print and *print-level*
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Nov 85 00:56:36 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 19 Nov 85 03:56:29-EST
Date: Tue, 19 Nov 1985 03:56 EST
Message-ID: <RAM.12160433529.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: :Structure-Print and *print-level*
The current depth in printing is an argument to defstruct
structure printing functions. If the print function calls print
recursively, should print start over again at zero, or do something
else? If the depth in printing is preserved across the call to the
structure-print function, should it be the same in the recursive call,
or one greater?
Rob
∂19-Nov-85 1346 KESSLER@UTAH-20.ARPA Universal Catch
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 13:46:40 PST
Date: Tue 19 Nov 85 14:45:20-MST
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Subject: Universal Catch
To: common-lisp@SU-AI.ARPA
Message-ID: <12160573501.22.KESSLER@UTAH-20.ARPA>
One of the "features" of PSL is that if the tag of a catch is NIL, then
that catch will catch any throw. This feature is especially nice when
writing top loops and similar functions that you want to permit
arbitrary interaction with throws. Does CL provide a similar functionality
(I haven't seen anything similar in the manual)? Is it an extension that
might be included in CL-86 (or whatever we call it)? Comments?
Bob.
-------
∂19-Nov-85 1645 REM@IMSSS CATCH-ALL
Received: from IMSSS by SU-AI with PUP; 19-Nov-85 16:45 PST
Date: 19 Nov 1985 1641-PST
From: Rem@IMSSS
Subject: CATCH-ALL
To: KESSLER%UTAH-20.ARPA@SCORE
cc: COMMON-LISP@SU-AI
MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too.
CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form).
But the ZetaLisp manual says if you think you need this you probably want
UNWIND-PROTECT instead.
Perhaps what we really need is an extra feature in UNWIND-PROTECT, whereby
the cleaup forms can find out why they are being called. Some global
variable can be SETQ'd by the unwinding mechanism, to NIL in the case of
falling out of the main form nomally, to ERROR in the case of an error
signal that is being passed up to an errset, or to the tag if a THROW
is happening. This would give the cleanup form the opportunity to
intercept certain tags in the same way CATCH-ALL did in MacLISP, but
maybe be a bit cleaner? Or maybe we really need CATCH-ALL because it
woul be cleaner than the enhanced UNWIND-PROTECT. Esthetic opinion anybody?
-------
∂19-Nov-85 1657 RWK@SCRC-YUKON.ARPA Universal Catch
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 16:57:15 PST
Received: from CROW.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 172000; Tue 19-Nov-85 19:56:36-EST
Date: Tue, 19 Nov 85 19:53 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Universal Catch
To: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12160573501.22.KESSLER@UTAH-20.ARPA>
Message-ID: <851119195331.3.RWK@CROW.SCRC.Symbolics.COM>
Date: Tue 19 Nov 85 14:45:20-MST
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
One of the "features" of PSL is that if the tag of a catch is NIL, then
that catch will catch any throw. This feature is especially nice when
writing top loops and similar functions that you want to permit
arbitrary interaction with throws. Does CL provide a similar functionality
(I haven't seen anything similar in the manual)? Is it an extension that
might be included in CL-86 (or whatever we call it)? Comments?
I don't understand how this helps write "top loops".
It sure makes it hard to figure out why your program suddenly
quit to top level because somewhere you misspelled HEIRARCHY
in a THROW. It's much more useful if it is an error.
I can think of other arbitrary interactions you could permit
with THROW; why is this one any better? ;-)
I think what you are really looking for here is a "catch-barrier",
which says "never throw above here", so you don't accidentally
throw out of your breakpoint or debugger? I think that's better,
but it makes it harder to deliberatly continue by throwing out
to some tag. If I remember right, I think NIL has such a feature.
∂19-Nov-85 1739 kessler%utah-orion@utah-cs.arpa Re: Universal Catch
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 17:36:49 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA17394; Tue, 19 Nov 85 18:36:48 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA07391; Tue, 19 Nov 85 18:36:45 MST
Date: Tue, 19 Nov 85 18:36:45 MST
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8511200136.AA07391@utah-orion.ARPA>
To: RWK@scrc-yukon.arpa
Subject: Re: Universal Catch
Cc: common-lisp@su-ai.arpa
Yes, a catch barrier is what I am thinking about. My top loop analogy
was just that, you want to be able to keep any errors or extraneous throws
from leaving your top loop. One does need to be able to get the value
of the tag though. I suppose that one could use a really disgusting
hack with unwind-protect where instead of exiting in the cleanup forms,
the code could recursively call the top loop. Geez that would be a real
hack ;-)
Bob.
∂19-Nov-85 1925 GSB@MIT-MC.ARPA catching
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 19:25:15 PST
Date: Tue, 19 Nov 85 22:27:38 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
Subject: catching
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].724785.851119.GSB>
NIL contains two undocumented special operators CATCHALL and
CATCH-BARRIER.
CATCHALL takes an argument list (function &body body). It evaluates
and saves function, then evaluates the body as a progn. If a THROW is
performed through this construct, the function gets invoked on two
arguments: the tag being thrown to, and the value being thrown.
Obviously this is incorrect wrt throwing multiple values; the obvious
correction is to make the function get called on all of the values
being thrown. The idea is, however, that one can inspect the tag and
repeat the throw as if nothing had happened. Normal return, and
abnormal returns that do not use THROW (we have a
force-return-from-function-call-frame operation in NIL for use by the
debugger) do not invoke the catchall function, even though they would
invoke the cleanup forms of an unwind-protect. And, there are NO
special catch tags; they are objects compared with EQ.
CATCH-BARRIER is just like CATCH, except that it effectively makes all
established CATCH tags outside of its dynamic scope invisible. I.e.,
(catch 'foo
(catch-barrier 'bar
(throw 'foo t)))
will complain that FOO is an unseen catch tag.
∨
∂19-Nov-85 1941 @MIT-MC.ARPA:BROOKS@MIT-OZ Re: Universal Catch
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 19:40:06 PST
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 NOV 85 21:52:51 EST
Date: Tue 19 Nov 85 21:48:59-EST
From: "Rodney A. Brooks" <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Universal Catch
To: kessler%utah-orion@UTAH-CS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8511200136.AA07391@utah-orion.ARPA>
Message-ID: <12160628778.50.BROOKS@MIT-OZ>
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8511200136.AA07391@utah-orion.ARPA>
To: RWK@scrc-yukon.arpa
Subject: Re: Universal Catch
Cc: common-lisp@su-ai.arpa
Yes, a catch barrier is what I am thinking about. My top loop analogy
was just that, you want to be able to keep any errors or extraneous throws
from leaving your top loop. One does need to be able to get the value
of the tag though. I suppose that one could use a really disgusting
hack with unwind-protect where instead of exiting in the cleanup forms,
the code could recursively call the top loop. Geez that would be a real
hack ;-)
Bob.
You don't need a recursive call. Below will keep doing <stuff> forever.
(loop (block toplevel
(unwind-protect <stuff>
(return-from toplevel nil))))
Of course it doesn't give you access to the tag that was thrown to.
-------
∂20-Nov-85 0050 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Extra paren in example on p.430
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 00:47:16 PST
Received: from tektronix by csnet-relay.csnet id ab08617; 20 Nov 85 3:38 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Fcc: cl-mail
Received: from tekchips by tektronix with smtp ; 19 Nov 85 13:14:59 PST
Date: Tuesday, 19 Nov 85 13:00:45 PST
Subject: Extra paren in example on p.430
The fourth line in the definition of the function
command-dispatch, the book shows
(funcall fn))
it should be (funcall fn)
--sridhar
∂20-Nov-85 0911 gls@THINK-AQUINAS.ARPA Extra paren in example on p.430
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 20 Nov 85 09:11:27 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1727; Wed 20-Nov-85 10:18:21-EST
Date: Wed, 20 Nov 85 10:18 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Extra paren in example on p.430
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 19 Nov 85 16:00-EST from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-ID: <851120101831.3.GLS@FAUSTINUS.THINK.COM>
Date: Tuesday, 19 Nov 85 13:00:45 PST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
The fourth line in the definition of the function
command-dispatch, the book shows
(funcall fn))
it should be (funcall fn)
--sridhar
Right you are. Thank you.
--Guy
∂20-Nov-85 1139 gls@THINK-AQUINAS.ARPA Extra paren in example on p.430
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 20 Nov 85 09:11:27 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1727; Wed 20-Nov-85 10:18:21-EST
Date: Wed, 20 Nov 85 10:18 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Extra paren in example on p.430
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 19 Nov 85 16:00-EST from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-ID: <851120101831.3.GLS@FAUSTINUS.THINK.COM>
Date: Tuesday, 19 Nov 85 13:00:45 PST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
The fourth line in the definition of the function
command-dispatch, the book shows
(funcall fn))
it should be (funcall fn)
--sridhar
Right you are. Thank you.
--Guy
∂20-Nov-85 1148 BSG@SCRC-STONY-BROOK.ARPA CATCH-ALL
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 11:48:04 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 358764; Wed 20-Nov-85 12:42:13-EST
Date: Wed, 20 Nov 85 12:45 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: CATCH-ALL
To: Rem@IMSSS, KESSLER%UTAH-20.ARPA@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS
Message-ID: <851120124522.4.BSG@CONCORD.SCRC.Symbolics.COM>
Date: 19 Nov 1985 1641-PST
From: Rem@IMSSS
MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too.
CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form).
But the ZetaLisp manual says if you think you need this you probably want
UNWIND-PROTECT instead.
Perhaps what we really need is an extra feature in UNWIND-PROTECT, whereby
the cleaup forms can find out why they are being called. Some global
variable can be SETQ'd by the unwinding mechanism, to NIL in the case of
falling out of the main form nomally, to ERROR in the case of an error
signal that is being passed up to an errset, or to the tag if a THROW
is happening. This would give the cleanup form the opportunity to
intercept certain tags in the same way CATCH-ALL did in MacLISP, but
maybe be a bit cleaner? Or maybe we really need CATCH-ALL because it
woul be cleaner than the enhanced UNWIND-PROTECT. Esthetic opinion anybody?
-------
I think this is all pretty disgusting, and a blatant controversion of
modularity. I'd like to hear the proposed use of CATCH-ALL, or
whatever. Please don't confuse it with a need to catch all -errors-,
which is a function of an error system, not catch/throw semantics.
∂20-Nov-85 1417 Moon@SCRC-QUABBIN.ARPA Fill-pointers and sequences
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:15:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222518; Wed 20-Nov-85 17:14:20-EST
Date: Wed, 20 Nov 85 17:14 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Fill-pointers and sequences
To: Common-Lisp@SU-AI.ARPA
Message-ID: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Consider this code:
(setq a (make-array 10 :fill-pointer 3))
(fill a nil :start (fill-pointer a) :end (array-dimension a 0))
Is this correct Common Lisp? In our implementation this signals an
error that you are accessing outside the bounds of the sequence, but
I believe that is not correct. It is accessing outside the bounds
of the sequence, defined by its fill-pointer, but it is not accessing
outside the bounds of the array.
An example application would be filling the part of a array past its
fill-pointer with its initial-element, so the garbage collector doesn't
have to preserve objects referenced by leftover array contents there.
I checked the Common Lisp manual carefully, and it never says what the
legal values for the :start and :end arguments to a sequence function
are, except that :start must not be > than :end. :end defaults to the
fill-pointer, but it is not clear that it is an error for :end to be
specified larger than the fill-pointer. Perhaps the answer depends on
exactly how we are to interpret the use of the word "subsequence" in the
first sentence of the last paragraph on page 246. Does the answer
depend on whether the sequence function in question is one that writes
(like FILL or REPLACE) or one that reads (like POSITION or REMOVE)?
Does anyone have an opinion to offer?
∂20-Nov-85 1428 Moon@SCRC-QUABBIN.ARPA Universal Catch
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:28:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222525; Wed 20-Nov-85 17:26:48-EST
Date: Wed, 20 Nov 85 17:26 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Universal Catch
To: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12160573501.22.KESSLER@UTAH-20.ARPA>
Message-ID: <851120172629.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue 19 Nov 85 14:45:20-MST
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
One of the "features" of PSL is that if the tag of a catch is NIL, then
that catch will catch any throw. This feature is especially nice when
writing top loops and similar functions that you want to permit
arbitrary interaction with throws.
Please don't confuse THROW with ERROR. They are different functions for
different purposes.
I realize it's difficult, because Common Lisp hasn't yet acquired an
error-handling system, only a (primitive) error-signalling system. That
happened because of deadline pressure in getting out the original
language specification.
Good proposals have been made, they only need to be finished. I hope
this deficiency of Common Lisp can be rectified in finite time; all it
takes is someone to write a complete proposal and an institutional
context for creating a revised language specification.
Does CL provide a similar functionality
(I haven't seen anything similar in the manual)? Is it an extension that
might be included in CL-86 (or whatever we call it)? Comments?
Early versions of Common Lisp contained primitives called CATCH-ALL and UNWIND-ALL.
After discussion, they were removed. They definitely should not be put back in.
∂20-Nov-85 1429 Moon@SCRC-QUABBIN.ARPA CATCH-ALL
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:29:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222527; Wed 20-Nov-85 17:27:43-EST
Date: Wed, 20 Nov 85 17:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: CATCH-ALL
To: Rem@IMSSS
cc: KESSLER%UTAH-20.ARPA@SU-SCORE.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS
Message-ID: <851120172724.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 19 Nov 1985 1641-PST
From: Rem@IMSSS
MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too.
CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form).
But the ZetaLisp manual says if you think you need this you probably want
UNWIND-PROTECT instead.
Just to set the record straight, Zetalisp does not contain CATCH-ALL.
∂20-Nov-85 1432 Moon@SCRC-QUABBIN.ARPA CATCH-ALL
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:32:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222529; Wed 20-Nov-85 17:28:39-EST
Date: Wed, 20 Nov 85 17:28 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: CATCH-ALL
To: Rem%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS
Message-ID: <851120172830.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 19 Nov 1985 1641-PST
From: Rem@IMSSS
MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too.
CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form).
But the ZetaLisp manual says if you think you need this you probably want
UNWIND-PROTECT instead.
Just to set the record straight, Zetalisp does not contain CATCH-ALL.
∂20-Nov-85 1729 FAHLMAN@C.CS.CMU.EDU Fill-pointers and sequences
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Nov 85 17:29:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 Nov 85 20:29:15-EST
Date: Wed, 20 Nov 1985 20:29 EST
Message-ID: <FAHLMAN.12160876394.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Fill-pointers and sequences
In-reply-to: Msg of 20 Nov 1985 17:14-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
It seems to me that this is a question of what abstraction we want to
associate with the concept of a "sequence": when a vector is treated as
a sequence, is the sequence only that part of the vector up to the fill
pointer, or the whole thing? I think that we have pretty consistently
adhered to the former view. The :start and :end defaults suggest this,
as do the definitions for functions like Length. Aref is allowed to
reference past the fill pointer, but this is noted in the manual as an
exceptional case.
So if we want to be consistent and minimize confusion, I would argue
that sequence functions should signal an error (or at least that it
should "be an error") if we try to make such functions access past the
fill pointer. This supports the abstraction that moving the fill
pointer changes the legnth of the sequence. I think that's what we had
in mind when we put this stuff in, though of course we might not all
have had the same things in mind.
As an additional argument, on page 295 of the manual it says the
following: "Nearly all functions that operate on the contents of a
vector operate only on the active elements. An important exception is
Aref ..." A good lawyer could wiggle out of this, but it seems that
this is trying to tell us that vanilla sequence functions should not be
allowed to do things to elements past the fill pointer.
-- Scott
∂21-Nov-85 0702 FAHLMAN@C.CS.CMU.EDU :Structure-Print and *print-level*
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Nov 85 07:02:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 21 Nov 85 10:02:39-EST
Date: Thu, 21 Nov 1985 10:02 EST
Message-ID: <FAHLMAN.12161024452.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: :Structure-Print and *print-level*
In-reply-to: Msg of 19 Nov 1985 03:56-EST from Rob MacLachlan <RAM>
The current depth in printing is an argument to defstruct
structure printing functions. If the print function calls print
recursively, should print start over again at zero, or do something
else? If the depth in printing is preserved across the call to the
structure-print function, should it be the same in the recursive call,
or one greater?
Rob
I was hoping that someone who had thought a lot about printing issues
would jump up and take a crack at this, but since nobody has, I'll give
it a try. I haven't dealt with printer issues much, so if somebody sees
a deep bogosity in my analsysis, please step forward.
When built-in data structures are being printed, each level of recursion
into sub-structure bumps some hidden counter by 1, and when this value
exceeds *print-level*, the printing becomes terse. This facility is not
accessible to the user in any way that I can see -- either there is some
special internal call to print that takes a current-depth argument or
print looks at some undocumented special to get this sort of behavior.
The user-accessible Print function, as it is currently defined, would
seem always to set the print-depth back to zero when called explicitly.
At least, in my quick scan of the manual I didn't see any way of doing
this.
The obvious intent in structure printing is that we want users to be
able to write print functions that mimic the behavior of built-in print
methods -- in this way, we hope to make the user-defined structures act
like built-in data types. So the right thing to do would be to let
these print functions access the current depth, and let them call the
print functions, explicitly passing on the depth argument, usually
incremented by one.
Well, I think we blew it, since user-code has no way of calling Print
and friends with an explicit depth argument, incremented or not. It
would be possible to add some magic kludge whereby Print and friends
realize that they are being called recursively within a structure-print
routine and somehow figure out what the current depth ought to be. That
stikes me as being very confusing and dangerous. I would suggest that
Print and friends continue to reset the depth to zero when called
explicitly, but that sometime soon we should provide a way of slipping
some non-zero current depth to these functions explicitly. This should
probably be done with an additional optional or keyword arg to the
existing print functions (or maybe just to Write).
-- Scott
∂21-Nov-85 0741 gls@THINK-AQUINAS.ARPA Fill-pointers and sequences
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85 07:41:17 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1935; Thu 21-Nov-85 10:42:42-EST
Date: Thu, 21 Nov 85 10:42 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Fill-pointers and sequences
To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851121104241.1.GLS@FAUSTINUS.THINK.COM>
There are two other passages you might consider. First, page 246, last
paragraph, states that the :start and :end arguments should be integer
indices "into the sequence"; is an index larger than the fill pointer
"into the sequence" or merely "into the vector"? Second, page 291 notes
that "aref is unusual among the functions that operate on arrays in that
it completely ignores fill pointers". If we really believed the book to
be careful and accurate, we might infer that other functions not
specifically documented to be in this unusual category may not access
beyond the fill pointer; but in the actual event this inference is shaky
at best.
I think I would be inclined to write the code in this manner:
(setq a (make-array 10 :fill-pointer 3))
(let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a))))
(fill a nil :start (fill-pointer a) :end (array-dimension a 0))
(setf (fill-pointer a) old-fill-pointer))
or, for the truly worried,
(let ((old-fill-pointer (array-total-size a)))
(unwind-protect
(progn (setf (fill-pointer a) (array-total-size a))
(fill a nil :start (fill-pointer a) :end (array-dimension a 0)))
(setf (fill-pointer a) old-fill-pointer)))
I do not feel strongly about which way this issue is resolved, but I
agree that it should be tied down. I mildly favor a strict interpretation.
--Guy
∂21-Nov-85 0844 gls@THINK-AQUINAS.ARPA Fill-pointers and sequences
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85 07:41:17 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1935; Thu 21-Nov-85 10:42:42-EST
Date: Thu, 21 Nov 85 10:42 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Fill-pointers and sequences
To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851121104241.1.GLS@FAUSTINUS.THINK.COM>
There are two other passages you might consider. First, page 246, last
paragraph, states that the :start and :end arguments should be integer
indices "into the sequence"; is an index larger than the fill pointer
"into the sequence" or merely "into the vector"? Second, page 291 notes
that "aref is unusual among the functions that operate on arrays in that
it completely ignores fill pointers". If we really believed the book to
be careful and accurate, we might infer that other functions not
specifically documented to be in this unusual category may not access
beyond the fill pointer; but in the actual event this inference is shaky
at best.
I think I would be inclined to write the code in this manner:
(setq a (make-array 10 :fill-pointer 3))
(let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a))))
(fill a nil :start (fill-pointer a) :end (array-dimension a 0))
(setf (fill-pointer a) old-fill-pointer))
or, for the truly worried,
(let ((old-fill-pointer (array-total-size a)))
(unwind-protect
(progn (setf (fill-pointer a) (array-total-size a))
(fill a nil :start (fill-pointer a) :end (array-dimension a 0)))
(setf (fill-pointer a) old-fill-pointer)))
I do not feel strongly about which way this issue is resolved, but I
agree that it should be tied down. I mildly favor a strict interpretation.
--Guy
∂21-Nov-85 0846 gls@THINK-AQUINAS.ARPA :Structure-Print and *print-level*
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85 08:45:40 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1958; Thu 21-Nov-85 11:24:58-EST
Date: Thu, 21 Nov 85 11:25 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: :Structure-Print and *print-level*
To: Fahlman@CMU-CS-C.ARPA, RAM@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12161024452.BABYL@C.CS.CMU.EDU>
Message-ID: <851121112509.7.GLS@FAUSTINUS.THINK.COM>
Many thanks to Scott for illuminating this issue. The idea I had had
in mind was that the defstruct printing function would look something
like
(defun astronaut-print-fn (obj s depth)
(format s "[***>>> ASTRONAUT! Name: ")
(write (astro-name obj) :stream s :level (- *print-level* depth))
(format s " <<<***]"))
However, this is not quite the right thing if the originally specified
:level argument had not defaulted to the value of *print-level*.
One suggestion is to redefine the third argument to a structure print
function to be "depth remaining", to be compared against zero. Then
one would write
(defun astronaut-print-fn (obj s depth)
(format s "[***>>> ASTRONAUT! Name: ")
(write (astro-name obj) :stream s :level (- depth 1))
(format s " <<<***]"))
In retrospect, I think it was not defined this way because in MacLISP
I had frequently found it very convenient, when faced with a large
(possible infinite) printout, to do a break, set PRINLEVEL to some
finite value, and then resume, whereupon the printout would quickly
cut itself off, allowing computation to resume. The second treatment
shown above would not respond to dynamic changes in *PRINT-LEVEL*.
Is this important?
--Guy
∂21-Nov-85 1030 greek%bach.decnet@hudson.dec.com Recursive print & depth abbreviation
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85 10:28:20 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Recursive print & depth abbreviation
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
We really have two issues here.
First of all we need a recursive-p argument to the print functions,
including PRINT et al and FORMAT. This is for precisely the same
reasons as the read functions -- in order to print an object I may
have to use print functions recursively. It's not clear that there's a
good way to add recursive-p, especially since FORMAT already takes an
&rest argument. (Excluding FORMAT for some religious reason would be
wrong.)
The second issue is that of print depth. We never should have passed
the level to a structure print function. Instead we should have said
that the print system worries about print depth in some automatic
fashion. After all, the structure print function is going to utilize
the print system to print the structure, so the print system ought to be
able to do the depth abbreviation just fine. An example of how to do
this is given by Dick Waters' PP facility, which implements all
abbreviation more or less automatically.
Another case in which a top-level versus recursive print must be
distinguished is when the printing system buffers output. If you
interrupt it in the middle of a print and enter a break loop, clearly a
new set of buffers is required so that the original print can continue
undaunted later on. The break loop needs to start a new top-level
print. Hey, it's just like reading!
Passing a level or depth argument to the WRITE function is going to add
even more confusion (particularly given our silly definitions of
level vs. depth). Anyway, why have we demoted PRINT, PRINC, PRIN1, and
FORMAT to second class functions? Hell, everybody uses FORMAT in a
structure print function.
------
∂21-Nov-85 1214 hoey@nrl-aic Re: :Structure-Print and *print-level*
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 12:09:40 PST
Date: 21 Nov 1985 13:26:40 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: :Structure-Print and *print-level*
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Message-Id: <501445600/hoey@nrl-aic>
In-Reply-To: Guy Steele's message of Thu, 21 Nov 85 1125 EST
The idea I had had in mind was that the defstruct printing function
would look something like
(defun astronaut-print-fn (obj s depth)
(format s "[***>>> ASTRONAUT! Name: ")
(write (astro-name obj) :stream s :level (- *print-level* depth))
(format s " <<<***]"))
However, this is not quite the right thing if the originally specified
:level argument had not defaulted to the value of *print-level*.
Which arises if the printed representation of an astronaut can contain
the p. r. of another astronaut. But the real problem with this method
is that it confuses the two notions of print level and of print depth.
I see no problem with the hidden variable representing the depth in
printing functions. My expectation is that this variable should always
be incremented on entry to the function WRITE, and restored on exit.
In this way a user's printing functions that call PRINT or WRITE behave
the same way that WRITE does when it calls itself recursively.
One thing that may not be immediately apparent is that the depth should
be specific to each stream, so that a printing function that uses WRITE
on another stream (presumably as part of determining what its output
should be) is not affected by the depth of the stream that it is to
print its object on.
The assumption here is that during the period when a WRITE to a stream
is in progress, any recursive call to WRITE on that stream is for the
purpose of printing a part of the object for which the first WRITE was
issued. I can imagine cases for which this assumption might not be
appropriate:
-- some sort of random access scheme with an automatically-maintained
index of astronauts in some other part of the file, or
-- a debugging trap or trace output that occurs during printing,
where some extraneous material will appear in the middle of the
printed representation of the object,
but I think that both of these uses can be implemented in ways that do
not need to know how to access the hidden variable.
Dan
∂21-Nov-85 1313 greek%bach.decnet@hudson.dec.com Recursive printing.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85 13:09:16 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Recursive printing.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Apologies if you got an abbreviated version of this message.
Dan Hoey has certainly hit upon some of the problems with recursive
printing. And he has suggested, as we have, that depth abbreviation
could be handled automatically.
The right way to decide if a print is recursive is not by using
heuristics (like switching streams or entering break loops), but by
explicitly specifying it with recursive-p. The heuristics will only be
a hack. However, it certainly isn't clear how to add recursive-p to all
the appropriate functions.
Perhaps we can agree that depth abbreviation is to be done
automatically, but let's not specify how to do it.
------
∂21-Nov-85 1324 FAHLMAN@C.CS.CMU.EDU :Structure-Print and *print-level*
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Nov 85 13:24:44 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 21 Nov 85 16:24:31-EST
Date: Thu, 21 Nov 1985 16:24 EST
Message-ID: <FAHLMAN.12161093987.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dan Hoey <hoey@NRL-AIC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: :Structure-Print and *print-level*
In-reply-to: Msg of 21 Nov 1985 13:26-EST from Dan Hoey <hoey at nrl-aic.ARPA>
Hoey's proposal sounds good to me, at least as a pretty good way to
handle all this until we can modify the language to give the user more
explicit control. Maybe we should suggest this as the preferred thing
for an implementation to do, as the language stands now.
-- Scott
∂21-Nov-85 1402 greek%bach.decnet@hudson.dec.com Recursive printing.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85 13:59:08 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Recursive printing.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
What exactly is Hoey's proposal? It seems to be twofold.
1. Depth abbreviation is performed automatically by WRITE.
2. A top-level print is started when you print to a different stream
from the last print.
Is this correct?
------
∂21-Nov-85 1703 hoey@nrl-aic Re: Recursive printing.
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 17:03:15 PST
Date: 21 Nov 1985 18:18:28 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: Recursive printing.
To: "BACH::GREEK" <greek%bach.decnet@dec-hudson.ARPA>
Cc: Common-lisp@su-ai.ARPA
Message-Id: <501463108/hoey@nrl-aic>
In-Reply-To: "BACH::GREEK"'s message of 0 0 000000 EST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
What exactly is Hoey's proposal? It seems to be twofold.
1. Depth abbreviation is performed automatically by WRITE.
2. A top-level print is started when you print to a different stream
from the last print.
Is this correct?
No, that isn't what I proposed.
Point 1 is the rationale for the proposal. I would like to avoid
forcing people to scatter :RECURSIVELY-P's throughout their print
functions.
I proposed that a depth be maintained for every stream, and that WRITE
to a stream should increment that stream's depth at entry and restore
the depth on exit.
Your point 2, if I understand it correctly, is that there be some
notion of the current stream, and a single depth that applies to
whatever stream is current. A WRITE to the current stream increments
the depth; a WRITE to another stream sets the depth to 1 and sets the
current stream to that stream. Both depth and current stream are
restored on exit from WRITE.
Both proposals work for the normal case, when the user's printing
function does no output except for the object being printed.
Both proposals work for the case I am most concerned about, where
printing an object involves normal output on another stream.
Where the proposals differ is when printing an object involves output
on another stream, and the output on the other stream involves output
on the first stream. For instance, with
(defun astronaut-print-fn (obj s depth)
(format s "[ ~S in space ]"
(or (astro-name obj)
(progn (format (astro-control obj)
"My buddy is ~S. Who am I?~%"
(astro-buddy obj))
(read (astro-control obj))))))
if two anonymous astronauts are each other's buddies, they will try to
print each other to their respective name servers. If the name servers
are different, your proposal does not allow a depth cutoff, whereas mine
does.
I can't think of any reason why we should prefer one proposal over the
other, but they are different.
Dan
∂21-Nov-85 1913 robbins%bach.decnet@hudson.dec.com Recursive printing.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85 19:03:58 PST
Date: 0 0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: Recursive printing.
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Dan is right. It would be nice if people did not have to scatter RECURSIVE-P's
throughout their PRINT functions. It would also be nice if they did not have
to scatter them throughout their READ functions. However, they are needed in
both instances, unfortunately, they are only defined for READ.
The proposal:
" ... that a depth be maintained for every stream, and that WRITE to
a stream should increment that stream's depth at entry and restore
the depth on exit"
assumes that it is never the case that someone will want to start a new top
level print on a stream when there is printing in progress.
Incrementing a counter upon entry to WRITE will not handle the situation where
someone interrupts pretty printing and enters a break loop. Printing done
during the break loop should not be done as if it were nested within the pretty
print, it should be done as though it were at top level. How can this be
expressed without explicitly initiating a new top level print?
Without a way of explicitly starting a new top level print some heuristic
must be used to attempt to determine when a new top level print is started
within a recursive print. A good rule of thumb is that the use of a new stream
signals the start of a new top level print.
Dan's two astronaut print provides an example where the stream switch
heuristic fails. The break loop case provides an example where incrementing
the internal depth counter whenever WRITE is entered fails. The problem is
that we lack a mechanism for explicitly stating that a new top level print
is desired. Adding RECURSIVE-P give us this mechanism (although it does
not address the problem presented by FORMAT).
--Rich
------
∂22-Nov-85 0738 DLW@SCRC-STONY-BROOK.ARPA adjust-array with :initial-elements and fill pointers
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 07:33:03 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360372; Fri 22-Nov-85 10:30:23-EST
Date: Fri, 22 Nov 85 10:36 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: adjust-array with :initial-elements and fill pointers
To: common-lisp@SU-AI.ARPA
Supersedes: <851122103625.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851122103647.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Consider the following forms:
(setq a (make-array 5 :fill-pointer 3))
(adjust-array a 7 :initial-element 'b)
What should happen? On page 297, it says "The elements of the new array
that are not in the bounds of array are initalized to the
:initial-element". The question is whether the elements that follow the
fill pointer are considered to be within the "bounds of the array". The
sentence on page 295, "Nearly all functions that operate on the contents
of a vector will operate only on the active elements", is what makes
this issue less than perfectly clear.
Our recommendation is that the entire new array be initialized, despite
the presence of the fill pointer, and that adjust-array be clearly
designated as one of the exceptions to the "nearly all" phrase.
∂22-Nov-85 0826 greek%bach.decnet@hudson.dec.com Apology for our brain-damaged mailer.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 08:25:56 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Apology for our brain-damaged mailer.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
This is an apology from us DECies for our newly-acquired Wollongong Group
Arpanet mailer. The VAX LISP group doesn't manage the Arpanet software,
but we'll keep telling those who do about the problems.
I suppose the mail heading breaks ZMail and Babyl and other software.
Sorry.
- Paul
------
∂22-Nov-85 0856 KMP@SCRC-STONY-BROOK.ARPA adjust-array with :initial-elements and fill pointers
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 08:56:12 PST
Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360471; Fri 22-Nov-85 11:54:46-EST
Date: Fri, 22 Nov 85 11:55 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: adjust-array with :initial-elements and fill pointers
To: DLW@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851122103647.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851122115545.9.KMP@DUPAGE.SCRC.Symbolics.COM>
Date: Fri, 22 Nov 85 10:36 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Consider the following forms:
(setq a (make-array 5 :fill-pointer 3))
(adjust-array a 7 :initial-element 'b)
What should happen? On page 297, it says "The elements of the new array
that are not in the bounds of array are initalized to the
:initial-element". The question is whether the elements that follow the
fill pointer are considered to be within the "bounds of the array". The
sentence on page 295, "Nearly all functions that operate on the contents
of a vector will operate only on the active elements", is what makes
this issue less than perfectly clear.
Our recommendation is that the entire new array be initialized, despite
the presence of the fill pointer, and that adjust-array be clearly
designated as one of the exceptions to the "nearly all" phrase.
Given:
(setq a (make-array 5 :fill-pointer 3))
(setf (aref a 0) 'x)
(setf (aref a 2) 'z)
(adjust-array a 7 :initial-element 'b)
Which of the following are you proposing:
1. A = [ X ? Z ? ? B B ]
2. A = [ X ? Z B B B B ]
3. A = [ X B Z B B B B ]
4. A = [ B B B B B B B ]
5. Other (please specify)
CLtL doesn't seem to say what happens to the fill pointer if there was no fill
pointer specified in the ADJUST-ARRAY call but there was one specified to
MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS
or Scott should correct me if I'm wrong). DLW, I am not clear on whether you
are suggesting that it it be reset (ie, that it be the same as specifying
:FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate?
I would be curious to hear an elaboration of your motivation. In my mind, there
are reasons for believing any of these are reasonable -- depending on the
application, which suggests to me that finer control (ie, more keywords) rather
than some arbitrary decision may be the really right thing. Of course, the
default must be clarified in any case.
∂22-Nov-85 0938 robbins%bach.decnet@hudson.dec.com Recursive printing proposal
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 09:33:20 PST
Date: 0 0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: Recursive printing proposal
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
I propose that we add the following macro:
TOP-LEVEL-PRINT &BODY BODY
The macro is responsible for ensuring that any printing within BODY will
be started as a top level print.
This achieves what having RECURSIVE-P arguments to printing functions would
without breaking existing source code and without requiring any changes to
FORMAT.
I think that while we should specify that the printer automatically handles
depth abbreviation, we should not specify how it is to be implemented.
-- Rich
------
∂22-Nov-85 1015 RPG Reminder about the Common Lisp Meeting
To: Common-lisp@SU-AI.ARPA
I would like to remind you about the Common Lisp meeting, which will be
Monday, Tuesday, Wednesday, Decembers 9, 10, and 11; at:
Boston Marriott Hotel Copley Place
110 Huntington Avenue
Boston, Massachusetts 02117
(617)236-5800
The room will be ours from 8:30am until 6:00pm each of those days.
There is a block of rooms at that hotel set aside for us. I understand
that it is a fancy hotel, and the rooms are not cheap, even with
the discount I got for the meeting. The rooms are $100 single and
$115 double, which is $60 off the regular rate. When you make your
reservations, specifically mention the Common Lisp meeting.
Here is an important piece of information:
************************************************************************
* *
* The block of rooms will be held for us until November 25, and *
* they can be booked for the evenings of Decemeber 8, 9, 10. *
* *
************************************************************************
The usual caveats apply to this hotel: a reservation without
a guarantee will only hold the room until 6:00pm of the evening
of your arrival. A guarantee is usually an American Express card
number.
-rpg-
∂22-Nov-85 1106 robbins%bach.decnet@hudson.dec.com LET-IF
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 10:43:09 PST
Date: 0 0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: LET-IF
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Is there a good reason why we don't have a ZetaLisp style LET-IF special form?
Using PROGV to bind an item based on some trivial condition seems like
overkill to me.
-- Rich
------
∂22-Nov-85 1127 FAHLMAN@C.CS.CMU.EDU Recursive printing proposal
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 11:27:38 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 14:26:37-EST
Date: Fri, 22 Nov 1985 14:26 EST
Message-ID: <FAHLMAN.12161334664.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "BACH::ROBBINS" <robbins%bach.decnet@HUDSON.DEC.COM>
Cc: common-lisp <common-lisp@SU-AI.ARPA>
Subject: Recursive printing proposal
In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>
I think this would have to be a special form and not a macro, since it
cannot be implemented using existing forms. It might be better to add a
function to sense and setf the current print depth, and implement your
own macro in terms of that.
-- Scott
∂22-Nov-85 1156 greek%bach.decnet@hudson.dec.com TOP-LEVEL-PRINT macro.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 11:54:16 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: TOP-LEVEL-PRINT macro.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I'm not sure why a TOP-LEVEL-PRINT macro would have to be a special
form. It just generates whatever code the print system needs to realize
this is a top-level print. For example, it could bind a special
variable to zero and then execute the body. It only has to set the
state of the world so that the print system knows it's a top-level
print.
Don't want to restrict anything by saying there is something to fetch
and SETF, or whatever. There is no need to know how the print system
deals with TOP-LEVEL-PRINT.
- Paul
------
∂22-Nov-85 1143 FAHLMAN@C.CS.CMU.EDU LET-IF
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 11:42:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 14:41:52-EST
Date: Fri, 22 Nov 1985 14:41 EST
Message-ID: <FAHLMAN.12161337435.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: robbins%bach.decnet@HUDSON.DEC.COM
Cc: common-lisp <common-lisp@SU-AI.ARPA>
Subject: LET-IF
In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>
Is there a good reason why we don't have a ZetaLisp style LET-IF special form?
Using PROGV to bind an item based on some trivial condition seems like
overkill to me.
What would you use this for? Why not just rebind the variable to its
old value and then conditionally change it? Common Lisp is big enough
without adding special forms that would only be used only very rarely.
-- Scott
∂22-Nov-85 1208 DLW@SCRC-STONY-BROOK.ARPA adjust-array with :initial-elements and fill pointers
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:07:45 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360668; Fri 22-Nov-85 14:49:16-EST
Date: Fri, 22 Nov 85 14:55 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: adjust-array with :initial-elements and fill pointers
To: KMP@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851122115545.9.KMP@DUPAGE.SCRC.Symbolics.COM>
Message-ID: <851122145536.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 22 Nov 85 11:55 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Given:
(setq a (make-array 5 :fill-pointer 3))
(setf (aref a 0) 'x)
(setf (aref a 2) 'z)
(adjust-array a 7 :initial-element 'b)
Which of the following are you proposing:
1. A = [ X ? Z ? ? B B ]
2. A = [ X ? Z B B B B ]
3. A = [ X B Z B B B B ]
4. A = [ B B B B B B B ]
5. Other (please specify)
I am assuming that "in the bounds" means "less than 5". Therefore, I am
advocating choice number 1. See the definition of :initial-element on
page 297.
CLtL doesn't seem to say what happens to the fill pointer if there was no fill
pointer specified in the ADJUST-ARRAY call but there was one specified to
MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS
or Scott should correct me if I'm wrong). DLW, I am not clear on whether you
are suggesting that it it be reset (ie, that it be the same as specifying
:FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate?
I am also assuming that the fill pointer remains 3.
I would be curious to hear an elaboration of your motivation.
The feeling is that the programmer would reasonably expect this code to
initialize the elements beyond the fill pointer, so that when the fill
pointer is increased, instead of finding unpredictable junk in the
array, the contents will be what was specified by :initial-elements. It
seems like the most useful definition.
∂22-Nov-85 1224 Moon@SCRC-STONY-BROOK.ARPA LET-IF
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:24:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360684; Fri 22-Nov-85 15:06:01-EST
Date: Fri, 22 Nov 85 15:05 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: LET-IF
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: robbins%bach.decnet@HUDSON.DEC.COM,
common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: <FAHLMAN.12161337435.BABYL@C.CS.CMU.EDU>
Message-ID: <851122150515.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 22 Nov 1985 14:41 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Is there a good reason why we don't have a ZetaLisp style LET-IF special form?
Using PROGV to bind an item based on some trivial condition seems like
overkill to me.
What would you use this for? Why not just rebind the variable to its
old value and then conditionally change it? Common Lisp is big enough
without adding special forms that would only be used only very rarely.
What if the variable is unbound?
Not that I am advocating adding this to Common Lisp. There are things
that I firmly believe belong in Symbolics Common Lisp and equally firmly
believe do not belong in the Common Lisp language standard, which as you
say is quite large already.
∂22-Nov-85 1243 Moon@SCRC-STONY-BROOK.ARPA :Structure-Print and *print-level*
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:43:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360717; Fri 22-Nov-85 15:28:35-EST
Date: Fri, 22 Nov 85 15:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: :Structure-Print and *print-level*
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Guy Steele <gls@THINK-AQUINAS.ARPA>,
"BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
Dan Hoey <hoey@NRL-AIC.ARPA>,
"BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>,
Rob MacLachlan <RAM@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12161024452.BABYL@C.CS.CMU.EDU>,
<851121112509.7.GLS@FAUSTINUS.THINK.COM>,
<501445600/hoey@nrl-aic>,
<FAHLMAN.12161093987.BABYL@C.CS.CMU.EDU>,
<501463108/hoey@nrl-aic>,
The message from "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>,
<FAHLMAN.12161334664.BABYL@C.CS.CMU.EDU>,
The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <851122152746.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Introducing magic hidden variables and kludgey recursive-p arguments to control
them is inviting disaster. I'm strongly opposed to this. We've had some experience
with this in Zetalisp and it is not good. It is always better to pass this kind
of state around as explicit arguments than to put it in hidden variables.
I fail to see what was wrong with the suggestion in Fahlman's original message of
adding a :DEPTH argument to WRITE, which defaults to 0 but can be supplied by a
structure's print function if it so desires.
I should think the answer to the question of whether a structure's print
function should increment the depth that it received as an argument
before passing it on to WRITE is perfectly obvious: it depends on
whether the print function printed any left parentheses before calling
WRITE. I think the fact that the print system has no reasonable way to
tell whether the print function printed any left parentheses, other than
the print function telling it so, counters Greek's argument that the old
thing should be automatic. Suppose the print function uses brackets as
part of its syntax and wants them treated as equivalent to a level
of parentheses for depth-abbreviation purposes.
I'm not concerned about the case of print functions that call FORMAT. FORMAT is
a convenient abbreviation mechanism for writing code to do simple forms of
formatting quickly. If you need to do something more complicated, you don't add
a new feature to FORMAT, you use Lisp instead of the FORMAT string language.
∂22-Nov-85 1249 Moon@SCRC-STONY-BROOK.ARPA Fill-pointers and sequences
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:49:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360737; Fri 22-Nov-85 15:37:13-EST
Date: Fri, 22 Nov 85 15:36 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Fill-pointers and sequences
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851121104241.1.GLS@FAUSTINUS.THINK.COM>
Message-ID: <851122153632.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 21 Nov 85 10:42 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
There are two other passages you might consider. First, page 246, last
paragraph, states that the :start and :end arguments should be integer
indices "into the sequence"; is an index larger than the fill pointer
"into the sequence" or merely "into the vector"? Second, page 291 notes
that "aref is unusual among the functions that operate on arrays in that
it completely ignores fill pointers". If we really believed the book to
be careful and accurate, we might infer that other functions not
specifically documented to be in this unusual category may not access
beyond the fill pointer; but in the actual event this inference is shaky
at best.
I think I would be inclined to write the code in this manner:
(setq a (make-array 10 :fill-pointer 3))
(let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a))))
(fill a nil :start (fill-pointer a) :end (array-dimension a 0))
(setf (fill-pointer a) old-fill-pointer))
or, for the truly worried,
(let ((old-fill-pointer (array-total-size a)))
(unwind-protect
(progn (setf (fill-pointer a) (array-total-size a))
(fill a nil :start (fill-pointer a) :end (array-dimension a 0)))
(setf (fill-pointer a) old-fill-pointer)))
I do not feel strongly about which way this issue is resolved, but I
agree that it should be tied down. I mildly favor a strict interpretation.
Okay, but I have to ask what we gain by making the user go through this 5-line
rigamarole when a simple call to FILL would suffice if the language were defined
the other way. To me, the fill-pointer is simply the current length and doesn't
mean that the rest of the vector does not exist in any sense (see the note on
p.295 that vector elements not in the active region are still part of the vector).
I guess the language is going to be ugly either way.
I also want to repeat my query which no one addressed yet: Does the answer
depend on whether the sequence function in question is one that writes
(like FILL or REPLACE) or one that reads (like POSITION or REMOVE)?
∂22-Nov-85 1253 Moon@SCRC-STONY-BROOK.ARPA TYPEP and arrays of (SATISFIES F)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:52:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360754; Fri 22-Nov-85 15:46:04-EST
Date: Fri, 22 Nov 85 15:45 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: TYPEP and arrays of (SATISFIES F)
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851118163500.9.GLS@THINK-HILARION.ARPA>
Message-ID: <851122154519.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 18 Nov 85 16:35 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Bob Rorschach has raised the following question: what is the
result of (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10)))
supposed to be? Consider these special cases:
(TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE INTEGER)
'(ARRAY (SATISFIES FIXNUMP) (10)))
(TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE FIXNUM)
'(ARRAY (SATISFIES FIXNUMP) (10)))
We can easily dismiss the first case, because clearly an array
specialized to hold integers is not necessarily the same as one
specialized to hold fixnums. The second is more difficult. It happens
to be the case that FIXNUM and (SATISFIES FIXNUMP) are equivalent type
specifiers, but in many implementations SUBTYPEP cannot discern this
fact (and indeed is not required to).
When TYPEP sees a plain old SATISFIES specifier, it can just call the
function, but not so when it is the element type of an ARRAY specifier.
Returning NIL for (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10)))
seems consistent with the discussion on page 45 of the manual.
Referring to the last line on that page, in an implementation without a
specialized array type for elements of type (SATISFIES F), no object
can pass that test.
I guess it's still an open question whether every implementation should
be required to return T for (EQUAL-TYPEP 'FIXNUM '(SATISFIES FIXNUMP))
and hence T for (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE 'FIXNUM)
'(ARRAY (SATISFIES FIXNUMP) (10))).
Yes, I know EQUAL-TYPEP is not a standard Common Lisp function, but I
think you get what I mean by it. I don't think it would be a good idea
to require this, because you quickly open the door to questions like
"well, what about (SATISFIES SMALL-INTEGER-P) where somewhere in the
program it says (DEFUN SMALL-INTEGER-P (X) (FIXNUMP X))".
One way out (proposed language change) is to define TYPEP to be like
SUBTYPEP, in that it returns two values; if the first value is NIL, the
second value says whether that's a "no" or a "maybe". So for the
first special case above TYPE would return either NIL T or NIL NIL,
depending on the cleverness of the implementation, and for the second
special case would return either NIL NIL or T T.
I don't think we need to change the language.
∂22-Nov-85 1304 greek%bach.decnet@hudson.dec.com Common LISP is too big?
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 13:03:46 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Common LISP is too big?
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I'm not sure I understand everyone's attitude about Common LISP being
too big. Dave Moon has a construct he likes so much that he absolutely
believes it ought to be in Symbolics Common LISP but doesn't want anyone
else to have it. Perhaps he just thinks that for compatability with
ZetaLisp, which I guess makes some sense.
You know, we could certainly prevent the language from gaining weight by
leaving out an error handling system, an object system, windows, etc.
If we don't want to make the language larger than it is today, we should
have made it smaller in the first place. But we didn't.
- Paul
------
∂22-Nov-85 1304 robbins%bach.decnet@hudson.dec.com LET-IF
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 13:04:10 PST
Date: 0 0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: LET-IF
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
I will give an example to illustrate why I think that we need LET-IF.
If there is a clean way to get around my need for a conditional bind,
then please let me know.
(defvar *flag*)
(defun f ()
(let-if (some-condition-that-may-be-satisfied-several-times)
((*flag* nil))
;; large body that will call f recursively and possibly set *flag*
(when *flag*
;; perform special processing
)))
I don't want to have to double the size of the function by having the body
twice.
I can't use catch and throw when the event happens because I only wish to
note that the event has happened, not terminate processing.
The function f is to be called very frequently and I want it to be as
fast as possible, hence PROGV seems like overkill.
Binding *flag* to a mutable object ...
(let ((*flag* (if (condition) (cons nil nil) *flag*))) ...
seems like a real hack.
-- Rich
------
∂22-Nov-85 1305 KMP@SCRC-STONY-BROOK.ARPA Recursive printing proposal
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 13:05:48 PST
Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360771; Fri 22-Nov-85 15:57:13-EST
Date: Fri, 22 Nov 85 15:58 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Recursive printing proposal
To: Fahlman@C.CS.CMU.EDU
cc: robbins%bach.decnet@HUDSON.DEC.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12161334664.BABYL@C.CS.CMU.EDU>
Message-ID: <851122155820.2.KMP@DUPAGE.SCRC.Symbolics.COM>
Date: Fri, 22 Nov 1985 14:26 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think this would have to be a special form and not a macro, since it
cannot be implemented using existing forms.
It could be introduced as a function which took a printer continuation. A macro
could then be written by anyone who didn't like functional notation.
It might be better to add a function to sense and setf the current print depth,
and implement your own macro in terms of that.
I'd agree with adding such primitives, but I don't think this is a good way to
think about a toplevel printing abstraction. What if some day we decide there
is more to toplevel printing than just noticing when the depth gets reset to
zero. Better to have an abstraction which does "any necessary setup" for printing
a toplevel object.
I'm not sure that this is a good abstraction to have, but if we have it, I think
that these thoughts are relevant.
I do know that I think we should have had an INVOKE-TOPLEVEL-READER abstraction
rather than passing around recursive-p information.
I guess I'd be willing to consider a function like the following:
PRINT-OBJECT-TOPLEVEL OBJECT &KEY FUNCTION STREAM
which could be described to do something roughly like the following, plus any
system-specific stuff which didn't interfere with the basic idea ... whatever
that means (sigh) ...
(DEFUN PRINT-OBJECT-TOPLEVEL (OBJECT &KEY FUNCTION STREAM)
(LET ((*STANDARD-OUTPUT* (OR STREAM *STANDARD-OUTPUT*)))
(LET ((OLD-DEPTH (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*)))
(UNWIND-PROTECT (PROGN (SETF (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*) 0)
(FUNCALL (OR FUNCTION #'PRIN1) OBJECT))
(SETF (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*) OLD-DEPTH)))))
∂22-Nov-85 1321 KMP@SCRC-STONY-BROOK.ARPA adjust-array with :initial-elements and fill pointers
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 13:21:12 PST
Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360792; Fri 22-Nov-85 16:05:11-EST
Date: Fri, 22 Nov 85 16:06 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: adjust-array with :initial-elements and fill pointers
To: DLW@SCRC-QUABBIN.ARPA, KMP@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851122145536.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851122160610.3.KMP@DUPAGE.SCRC.Symbolics.COM>
Date: Fri, 22 Nov 85 14:55 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Fri, 22 Nov 85 11:55 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Given:
(setq a (make-array 5 :fill-pointer 3))
(setf (aref a 0) 'x)
(setf (aref a 2) 'z)
(adjust-array a 7 :initial-element 'b)
Which of the following are you proposing:
1. A = [ X ? Z ? ? B B ]
2. A = [ X ? Z B B B B ]
3. A = [ X B Z B B B B ]
4. A = [ B B B B B B B ]
5. Other (please specify)
I am assuming that "in the bounds" means "less than 5". Therefore, I am
advocating choice number 1. See the definition of :initial-element on
page 297.
Oh, ok. I couldn't imagine that you were suggesting #1. I'm glad I asked.
#1 sounds fine to me.
CLtL doesn't seem to say what happens to the fill pointer if there was no fill
pointer specified in the ADJUST-ARRAY call but there was one specified to
MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS
or Scott should correct me if I'm wrong). DLW, I am not clear on whether you
are suggesting that it it be reset (ie, that it be the same as specifying
:FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate?
I am also assuming that the fill pointer remains 3.
I would be curious to hear an elaboration of your motivation.
The feeling is that the programmer would reasonably expect this code to
initialize the elements beyond the fill pointer, so that when the fill
pointer is increased, instead of finding unpredictable junk in the
array, the contents will be what was specified by :initial-elements. It
seems like the most useful definition.
Although, interestingly, in this example, elements 3 and 4 will (rightly) contain
unpredictable junk. I think we agree even though I don't think what you said
in this paragraph is true. I believe what you meant is that in the case of:
(setq a (make-array 5 :fill-pointer 3
:initial-element 'q)) ;added this
(setf (aref a 0) 'x)
(setf (aref a 2) 'z)
(adjust-array a 7 :initial-element 'b)
he has a right to expect that information beyond element 2 will not be junk
(ie, slots 3 and 4 will contain non-junk from the MAKE-ARRAY and slots
5 and 6 will contain non-junk from the ADJUST-ARRAY).
∂22-Nov-85 1328 FAHLMAN@C.CS.CMU.EDU Fill-pointers and sequences
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 13:23:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 16:22:42-EST
Date: Fri, 22 Nov 1985 16:22 EST
Message-ID: <FAHLMAN.12161355803.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Fill-pointers and sequences
In-reply-to: Msg of 22 Nov 1985 15:36-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I do not feel strongly about which way this issue is resolved, but I
agree that it should be tied down. I mildly favor a strict interpretation.
Okay, but I have to ask what we gain by making the user go through this 5-line
rigamarole when a simple call to FILL would suffice if the language were defined
the other way. To me, the fill-pointer is simply the current length and doesn't
mean that the rest of the vector does not exist in any sense (see the note on
p.295 that vector elements not in the active region are still part of the vector).
I guess the language is going to be ugly either way.
I also want to repeat my query which no one addressed yet: Does the answer
depend on whether the sequence function in question is one that writes
(like FILL or REPLACE) or one that reads (like POSITION or REMOVE)?
We've got two data abstractions going here: the sequence and the vector
which implements it. I am suggesting that the stuff beyond the fill
pointer is in the vector, but not in the sequence. What we gain is a
nice clean image of what the sequence is, without a lot of special
cases. In my opinion, the read/write distinction should not matter --
generic sequence functions should not read or write beyond the current
boundaries of the sequence, though vector/array primitives like AREF and
SVREF may do so.
-- Scott
∂22-Nov-85 1331 FAHLMAN@C.CS.CMU.EDU LET-IF
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 13:28:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 16:28:09-EST
Date: Fri, 22 Nov 1985 16:28 EST
Message-ID: <FAHLMAN.12161356793.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp <common-lisp@SU-AI.ARPA>
Subject: LET-IF
In-reply-to: Msg of 22 Nov 1985 15:05-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
What if the variable is unbound?
Well, in that case it usually does no harm to rebind the thing
unconditionally. The code would then look like
(let ((foo (if (boundp foo) foo foo-default)))
...)
I grant that a user might want to use a macro to abbreviate the above
idiom if it is used a lot, but it is probably not something that is used
enough to belong in the langauge proper. Are there other common uses of
LET-IF that would not be captured adequately by something like the
above?
-- Scott
∂22-Nov-85 1352 FAHLMAN@C.CS.CMU.EDU Recursive printing proposal
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 13:52:04 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 16:51:36-EST
Date: Fri, 22 Nov 1985 16:51 EST
Message-ID: <FAHLMAN.12161361052.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Recursive printing proposal
In-reply-to: Msg of 22 Nov 1985 15:58-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
The right way to fix this is to give the user some way to obtain the
current depth (the structure printing stuff already has this), and some
way to pass the depth to use as an optional or keyword argument to Write
(and maybe to the other printing thingies). This seems much simpler to
me than adding printer continuations and such to the language. The
other suggestions were merely for quick and dirty fixes that might fall
within the current language spec, but I guess we'd better not play that
game lest such things get locked in.
-- Scott
∂22-Nov-85 1419 greek%bach.decnet@hudson.dec.com Sigh on recursive printing.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 14:18:33 PST
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Sigh on recursive printing.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Passing around the current depth is NOT a reasonable solution.
Perhaps you folks aren't reading our mail because of the screwed
up date (although why your mail readers care about our date I'll
never understand).
Anyway, the solutions in order of cleanliness seem to me:
1. Add a recursive-p argument to ALL the printing functions.
2. Implement some kind of TOP-LEVEL-PRINT macro.
3. Add a depth argument to ALL the printing functions. Why are
you assuming that top-level prints only affect the depth? They
may do all sorts of other things.
Since we aren't likely to accept 1 or 3 because we can't add arguments
to functions, then it looks like 2.
- Paul
------
∂22-Nov-85 1430 FAHLMAN@C.CS.CMU.EDU LET-IF
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 14:29:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 17:28:39-EST
Date: Fri, 22 Nov 1985 17:28 EST
Message-ID: <FAHLMAN.12161367808.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "BACH::ROBBINS" <robbins%bach.decnet@HUDSON.DEC.COM>
Cc: common-lisp <common-lisp@SU-AI.ARPA>
Subject: LET-IF
In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>
(defvar *flag*)
(defun f ()
(let-if (some-condition-that-may-be-satisfied-several-times)
((*flag* nil))
;; large body that will call f recursively and possibly set *flag*
(when *flag*
;; perform special processing
)))
It's hard for me to see exactly what is intended here, since I think
you've got some bugs in your example. If that condition isn't true,
*flag* stays unbound and the WHEN form gets an error. It looks to me
like you're trying to establish some sort of handler whenever you find
the hairy condition to be true, so that when you emerge from the body
you will do something at this level (only) whenever the flag has been
set. But in the code you give, the "special processing" will occur at
all calls to F between the place where flag is set and the innermost
surrounding F where the condition was true.
I think that in most cases I would be inclined to handle this upward
communication by the return value rather than by side-effecting some
conditionally bound variable. It's less confusing that way.
But if you must do something like this, I see no reason not to use
PROGV. It shouldn't be any more inefficient than any other way of
binding a special, as long as the list of variables is a quoted constant
at compile time. If your local compiler generates lousy code for PROGV,
it should be easy to add an optimization to handle the
constant-variable-list case as efficiently as any other binding of a
special. If you don't like the looks of PROGV, then you can easily
write your own LET-IF macro in terms of PROGV, as long as you restrict
this form to binding special variables only. I perhaps mistakenly
assumed that the "overkill" you referred to earlier was in being forced
to use a special variable when you wanted a lexical one, but that is not
the case in your example.
-- Scott
∂22-Nov-85 1515 JAR@MIT-MC.ARPA LET-IF
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 14:42:46 PST
Date: Fri, 22 Nov 85 17:45:05 EST
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject: LET-IF
To: robbins%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM
In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>
Message-ID: <[MIT-MC.ARPA].729122.851122.JAR>
What's wrong with
(defmacro let-if (test bindings &body body)
(let ((f (gensym)))
`(flet ((,f () ,@body))
(if ,test (let ,bindings (,f)) (,f)))))
?
∂22-Nov-85 1636 DLW@SCRC-STONY-BROOK.ARPA Sigh on recursive printing.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 16:30:24 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361025; Fri 22-Nov-85 19:29:11-EST
Date: Fri, 22 Nov 85 19:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Sigh on recursive printing.
To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <851122193538.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Perhaps you folks aren't reading our mail because of the screwed
up date (although why your mail readers care about our date I'll
never understand).
Since you've mentioned this more than once: Zmail doesn't get broken in
any way by your messages. It understands that the header is illegal and
displays the message anyway. I am sending this message using the Zmail
"reply" command, and it had no trouble reversing the addresses. We
are receiving all your mail.
∂22-Nov-85 1722 GJC@MIT-MC.ARPA Recursive printing proposal
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 17:22:29 PST
Date: Fri, 22 Nov 85 20:24:55 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: Recursive printing proposal
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Fri 22 Nov 1985 16:51 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MIT-MC.ARPA].729486.851122.GJC>
One way to deal with printer extensions is to make them a bit more
formal, like the SETF extension mechanism which is less general then
macro definition but gets the intended job done with less duplicated work.
In the implementations that people have now I venture to say they could
look at the way that circular-print is handled, and build at least
PRINT-DEPTH handling into that. Maybe we should adopt a "programmable
printer" like that of Hawkinson, or a cleaned-up version of Waters?
∂22-Nov-85 1733 robbins%bach.decnet@hudson.dec.com LET-IF
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 17:33:01 PST
Date: 0 0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: LET-IF
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Both Jonathan and Scott have suggested methods to deal with the
situation that I posed. While LET-IF is certainly not required
I still think it would be worth having in the language. Sigh.
-- Rich
------
∂22-Nov-85 1743 Moon@SCRC-QUABBIN.ARPA Sigh on recursive printing.
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 17:38:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 223229; Fri 22-Nov-85 20:36:20-EST
Date: Fri, 22 Nov 85 20:36 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Sigh on recursive printing.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
cc: common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <851122203606.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 0 0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Perhaps you folks aren't reading our mail because of the screwed
up date (although why your mail readers care about our date I'll
never understand).
Never? I like being able to sort conversations into chronological order
so I have a hope of understanding them when I read them. Unpredictable
network delays frequently cause messages to get out of order.
∂22-Nov-85 1743 GJC@MIT-MC.ARPA LET-IF
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 17:39:25 PST
Date: Fri, 22 Nov 85 20:41:51 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: LET-IF
To: robbins%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM
In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>
Message-ID: <[MIT-MC.ARPA].729508.851122.GJC>
Funny you should mention that, I'm considering flushing quite a few
special forms in the LMI system and replacing them with macros, LET-IF
is one, and the following definition seems right:
(defmacro let-if (pred bindings &body body)
(let ((f (gentemp "f)))
`(flet ((,f () ,@body))
(if ,pred (let ,bindings (,f)) (,f)))))
The are similar constructions that conditionally bind dynamic things of
various kinds that are already implemented by taking advantage of
lexical scoping, CONDITION-BIND-IF (conditionally binding error handling)
is one fairly common form:
(condition-bind-if (not *debugging*) (x) (form) (error x)) for example.
Anyway, FLET is an ideal tool for avoiding what you describe as
"I don't want to have to double the size of the function by having the
body twice"
Or, as Mr Roberts would say, "can you say... CLOSURE," yes boys and girls...
∂23-Nov-85 0913 shebs%utah-orion@utah-cs.arpa Misc Queries
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 09:13:24 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA08458; Sat, 23 Nov 85 10:13:27 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA22920; Sat, 23 Nov 85 10:13:25 MST
Date: Sat, 23 Nov 85 10:13:25 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8511231713.AA22920@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Misc Queries
While working on PCLS, we've encountered some situations which are probably
trivial, but which I don't recall having been brought up:
1) What should (export nil) do? The CLM says that the first argument
is either a symbol or list of symbols, but doesn't tell how to handle
nil. Personally, I would prefer having nil mean an empty list, but Spice
code assumes you want to export the symbol nil.
2) The definition of macroexpand is that it does macroexpand-1 repeatedly,
while (for instance) PSL macroexpand tries to find all macros in a form
and expand them. Is CL macroexpand defined correctly? If so, is an
exhaustive macroexpander considered a compiler thing (because of the
need for special form knowledge)?
3) What is the general theory of destructive operations during lambda
list processing (such as by initforms)? For instance, how much structure
should be shared by an &rest binding and &key bindings?
4) What should happen if one does a defun with a documentation string
included, then later redefines the same function, but without specifying
a doc string? Should the old one go away? Spice Lisp seems to leave
it alone.
stan shebs
∂23-Nov-85 1348 DLW@SCRC-STONY-BROOK.ARPA Minor typo
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 13:45:42 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361428; Sat 23-Nov-85 16:43:13-EST
Date: Sat, 23 Nov 85 16:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Minor typo
To: common-lisp@SU-AI.ARPA
Message-ID: <851123164942.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
There seems to be a minor typo on page 23, second paragraph of 2.2.4,
second line, in which an existential qualifier symbol appears where
there ought to be a numeral "3".
∂23-Nov-85 1356 Moon@SCRC-STONY-BROOK.ARPA Misc Queries
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 13:55:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361434; Sat 23-Nov-85 16:54:13-EST
Date: Sat, 23 Nov 85 16:53 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Misc Queries
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8511231713.AA22920@utah-orion.ARPA>
Message-ID: <851123165317.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 23 Nov 85 10:13:25 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
While working on PCLS, we've encountered some situations which are probably
trivial, but which I don't recall having been brought up:
1) What should (export nil) do? The CLM says that the first argument
is either a symbol or list of symbols, but doesn't tell how to handle
nil. Personally, I would prefer having nil mean an empty list, but Spice
code assumes you want to export the symbol nil.
The second sentence of the last paragraph on page 182 is quite explicit.
The Spice implementation is not the definition of the language.
2) The definition of macroexpand is that it does macroexpand-1 repeatedly,
while (for instance) PSL macroexpand tries to find all macros in a form
and expand them. Is CL macroexpand defined correctly?
What the book says is "correct" by definition. Whether it's the best possible
language definition is another matter.
If so, is an
exhaustive macroexpander considered a compiler thing (because of the
need for special form knowledge)?
Yes. It's a useful thing to have, but it isn't the same as the macroexpand
function. It's necessary to have something more general than this to implement
setf correctly, so I expect most implementations have this capability.
3) What is the general theory of destructive operations during lambda
list processing (such as by initforms)? For instance, how much structure
should be shared by an &rest binding and &key bindings?
This would be clearer if you gave an example. If you're thinking of something
like
(defun disgust (&rest r &key (a (setq r nil)) b)
(list a b))
(disgust :b 2)
or even worse
(defun disgust (&rest r &key (a (setf (second r) nil)) b)
(list a b))
(disgust :b 2)
I don't think we anticipated that anybody would try this when we were designing
the language. I'd be happy to say that each of these is an error.
I wasn't able to come up with any problematic examples that didn't involve
modifying the &rest argument. Did you have others in mind?
4) What should happen if one does a defun with a documentation string
included, then later redefines the same function, but without specifying
a doc string? Should the old one go away? Spice Lisp seems to leave
it alone.
It should go away; think about what happens if you changed the function so that
it no longer conforms to what the old documentation said.
The Spice implementation is not the definition of the language.
∂23-Nov-85 1429 FAHLMAN@C.CS.CMU.EDU Misc Queries
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Nov 85 14:29:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 23 Nov 85 17:29:29-EST
Date: Sat, 23 Nov 1985 17:29 EST
Message-ID: <FAHLMAN.12161630105.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Misc Queries
In-reply-to: Msg of 23 Nov 1985 16:53-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I agree with Moon's analysis of your queries.
Not only is the Spice implementation not the definition of the language,
but it has never been exhaustively tested for compliance with the manual
-- it is hard to get part-time undergrads (and overworked faculty
members) to do such tedious things, and we have never had sufficient
funding to hire people specifically to do testing. So Spice Lisp is
useful as an implementors kit (the best one I know of that you can get
for free) but nobody should be too surprised if it contains occasional
errors in odd corners.
-- Scott
∂23-Nov-85 1628 RPG Minor Typo = Major Faux Pas!
To: common-lisp@SU-AI.ARPA
Dan mentioned that an existential quantifier was mistyped at some
place where a 3 was meant. He meant to say the an existential
quantifier was mistyped *every* place a 3 was meant. I think the
spot to which he refers is a place where the TTY font for `3'
belongs, and that representation of `3' looks exactly like an
existential sign. This is because that is the best font Digital
Press could come up with.
-rpg-
∂23-Nov-85 1933 mips!escargot.earl@glacier Misc Queries
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 19:33:38 PST
Received: by glacier with Sendmail; Sat, 23 Nov 85 19:33:06 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
id AA28866; Sat, 23 Nov 85 15:40:25 pst
Received: by escargot.UUCP (4.12/4.7)
id AA13650; Sat, 23 Nov 85 15:38:07 pst
Date: Sat, 23 Nov 85 15:38:07 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8511232338.AA13650@escargot.UUCP>
To: shebs%utah-orion@utah-cs.ARPA
Cc: common-lisp@su-ai.ARPA
In-Reply-To: glacier!shebs%utah-orion@utah-cs.arpa's message of Sat, 23 Nov 85 10:13:25 MST
Subject: Misc Queries
Date: Sat, 23 Nov 85 10:13:25 MST
From: glacier!shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
While working on PCLS, we've encountered some situations which are probably
trivial, but which I don't recall having been brought up:
1) What should (export nil) do? The CLM says that the first argument
is either a symbol or list of symbols, but doesn't tell how to handle
nil. Personally, I would prefer having nil mean an empty list, but Spice
code assumes you want to export the symbol nil.
Since (export (nil)) gets you the symbol interpretation, (export nil)
should mean (export ()). This should be a general principle: things
that take symbols or lists of symbols interpret nil as (). Of
course, this an example of how bankrupt having () be a symbol is.
∂24-Nov-85 0930 shebs%utah-orion@utah-cs.arpa Re: Misc Queries
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 24 Nov 85 09:30:46 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA16140; Sun, 24 Nov 85 10:30:56 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA27238; Sun, 24 Nov 85 10:30:53 MST
Date: Sun, 24 Nov 85 10:30:53 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8511241730.AA27238@utah-orion.ARPA>
To: Moon@scrc-stony-brook.arpa, shebs%utah-orion@utah-cs.arpa
Subject: Re: Misc Queries
Cc: common-lisp@su-ai.arpa
Date: Sat, 23 Nov 85 16:53 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
The second sentence of the last paragraph on page 182 is quite explicit.
The Spice implementation is not the definition of the language.
Well, now that I notice the sentence, it's pretty plain! One of the
trouble with huge specs I suppose... The reason I brought up Spice's
behavior is that a lot of people have based their implementations on
it, so any wrongnesses in it will be propagated unawares. For instance,
the PCLS package system is actually derived indirectly from Spice, via
HP, who now presumably have something to fix in their implementation!
I don't mean to criticize Spice code either; by and large, it's some of
the cleanest implementation code I've seen, and we should all be thankful
to Fahlman & Co. for making it available.
3) What is the general theory of destructive operations during lambda
list processing (such as by initforms)? For instance, how much structure
should be shared by an &rest binding and &key bindings?
This would be clearer if you gave an example. If you're thinking of something
like
(defun disgust (&rest r &key (a (setq r nil)) b)
(list a b))
(disgust :b 2)
or even worse
(defun disgust (&rest r &key (a (setf (second r) nil)) b)
(list a b))
(disgust :b 2)
I don't think we anticipated that anybody would try this when we were designing
the language. I'd be happy to say that each of these is an error.
I wasn't able to come up with any problematic examples that didn't involve
modifying the &rest argument. Did you have others in mind?
How about
(defun more-disgusting (a &optional (b (setq a nil))) (list a b))
This is almost plausible (you could save a supplied-p for b), and the CLM
doesn't disallow it. Perhaps the spec could be modified to say that
initforms may refer to parameters on the left, but not modify them.
stan shebs
∂24-Nov-85 1500 Moon@SCRC-STONY-BROOK.ARPA Re: Misc Queries
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Nov 85 14:58:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361709; Sun 24-Nov-85 17:56:58-EST
Date: Sun, 24 Nov 85 17:55 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Misc Queries
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8511241730.AA27238@utah-orion.ARPA>
Message-ID: <851124175559.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 24 Nov 85 10:30:53 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
How about
(defun more-disgusting (a &optional (b (setq a nil))) (list a b))
This is almost plausible (you could save a supplied-p for b), and the CLM
doesn't disallow it.
I don't see anything at all problematic about this. a is just a variable like
any other variable. This doesn't have the problem that the previous examples
had, where the same data were being used for more than one argument: the rest
argument and the keyword arguments.
Perhaps the spec could be modified to say that
initforms may refer to parameters on the left, but not modify them.
I don't see any reason to change the language here.
∂25-Nov-85 0739 gls@THINK-AQUINAS.ARPA LET-IF
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85 07:39:08 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2671; Mon 25-Nov-85 10:41:36-EST
Date: Mon, 25 Nov 85 10:40 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: LET-IF
To: GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, robbins%HUDSON.DEC.COM@GODOT.THINK.COM,
gls@THINK-AQUINAS.ARPA
In-Reply-To: <[MIT-MC.ARPA].729508.851122.GJC>
Message-ID: <851125104047.2.GLS@FAUSTINUS.THINK.COM>
Date: Fri, 22 Nov 85 20:41:51 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
...
Or, as Mr Roberts would say, "can you say... CLOSURE," yes boys and girls...
Hurrah for closures! But did you mean "Mr. Roberts" or "Mr. Rogers"?
(I can't imagine Mr. Roberts talking about closures. Then again,
it's just as hard to image Mr. Rogers talking about it.)
--Guy
∂25-Nov-85 0747 gls@THINK-AQUINAS.ARPA Minor typo
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85 07:47:32 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2674; Mon 25-Nov-85 10:50:17-EST
Date: Mon, 25 Nov 85 10:49 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Minor typo
To: DLW@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851123164942.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851125104923.3.GLS@FAUSTINUS.THINK.COM>
Date: Sat, 23 Nov 85 16:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
There seems to be a minor typo on page 23, second paragraph of 2.2.4,
second line, in which an existential qualifier symbol appears where
there ought to be a numeral "3".
Aw, c'mon! I *know* the code font stinks...
--Guy
∂25-Nov-85 0752 gls@THINK-AQUINAS.ARPA Minor Typo = Major Faux Pas!
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85 07:52:05 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2676; Mon 25-Nov-85 10:54:48-EST
Date: Mon, 25 Nov 85 10:53 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Minor Typo = Major Faux Pas!
To: RPG@SU-AI.ARPA, common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 23 Nov 85 19:28-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851125105359.4.GLS@FAUSTINUS.THINK.COM>
Date: 23 Nov 85 1628 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
Dan mentioned that an existential quantifier was mistyped at some
place where a 3 was meant. He meant to say the an existential
quantifier was mistyped *every* place a 3 was meant. I think the
spot to which he refers is a place where the TTY font for `3'
belongs, and that representation of `3' looks exactly like an
existential sign. This is because that is the best font Digital
Press could come up with.
-rpg-
Similarly, on page 49, third line, you will see a terminal cursor
s
between "(integer " and " 2 -1)", and again on the next line.
That threw me during proofreading!
--Guy
∂25-Nov-85 1408 @SCRC-RIVERSIDE.ARPA:rsl@RUSSIAN.SPA.Symbolics.COM LET-IF
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 25 Nov 85 14:08:28 PST
Received: from CERRIDWYN.SSF.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 55745; Mon 25-Nov-85 17:16:31-EST
Received: from QUETZLCOATL.SSF.Symbolics.COM by CERRIDWYN.SSF.Symbolics.COM via CHAOS with CHAOS-MAIL id 55477; Mon 25-Nov-85 14:09:40-PST
Date: Mon, 25 Nov 85 14:08 PST
From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>
Subject: LET-IF
To: George J. Carrette <GJC@MIT-MC.ARPA>,
robbins%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM
In-Reply-To: <[MIT-MC.ARPA].729508.851122.GJC>
Message-ID: <851125140843.3.RSL@QUETZLCOATL.SSF.Symbolics.COM>
Reply-To: RSL@SCRC-STONY-BROOK.ARPA
Date: Fri, 22 Nov 85 20:41:51 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Funny you should mention that, I'm considering flushing quite a few
special forms in the LMI system and replacing them with macros, LET-IF
is one, and the following definition seems right:
(defmacro let-if (pred bindings &body body)
(let ((f (gentemp "f")))
`(flet ((,f () ,@body))
(if ,pred (let ,bindings (,f)) (,f)))))
Unfortunately, this doesn't work if you want the bindings to be lexical
instead of special bindings. Consider:
(defun xor (a b)
(let-if a ((b (not b)))
b))
Unless B is special, this won't work using your scheme.
∂25-Nov-85 1547 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Typos on p.284 and p.324
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 25 Nov 85 15:47:24 PST
Received: from tektronix by csnet-relay.csnet id ac04345; 25 Nov 85 18:38 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Fcc: cl-mail
Received: from tekchips by tektronix with smtp ; 25 Nov 85 09:45:08 PST
Date: Monday, 25 Nov 85 09:36:19 PST
Subject: Typos on p.284 and p.324
p.284: A minor grammatical typo :
Near the beginning of the last quarter of the page , the
sentence:
"means the approximately the same as" should read
"means approximately the same as"
p.324: The second and third line: From the trace , it would appear
that the second argument to the floor function was intended to be 3
and not 2. So the 2 in these two lines should be replaced by a 3.
p.67: Another one pointed out by a colleague: At the beginning of the
page it says: "The defun special form ...." and in the very next line
defun is said to be a macro. [ defun does not appear in the list
of special forms on p.57 ]. Light ?
--sridhar
∂25-Nov-85 1715 RPG New, Improved Agenda
To: Common-lisp@SU-AI.ARPA
Here is an outline of my idea of the agenda we should use for the
meeting:
Sunday Night:
Registration and intense lobyying
Monday, December 9
8:30am Welcome, registration, and coffee
(Registration information will used for updating the mailing
lists, possible dunning for expenses unless I can sweet talk
DARPA into fronting some money for this meeting, and for making
sure that the groups are represented.)
9:00am Charter Discussion
Noon Lunch. You are on your own for this.
1:30pm Charter/Validation Discussion
6:00pm Dinner (Intense Lobbying and Discussions)
Tuesday
8:30am Coffee
9:00am Charter/Validation/ANSI etc Discussion
12:00 Lunch. You are on your own.
1:30pm Object-oriented programming
6:00pm Dinner
Wednesday
8:30am Coffee
9:00am Windows
12:00 Lunch. You are on your own.
1:30pm Windows/Errors/Varia
5:00pm Hit the Road
During the Charter discussion, the following topics will be discussed:
Fahlman's Proposals
Inclusion of the recent minor changes and errata to the
Common Lisp specification
Publishing problems - Copyright, additions to the book
Validation
Real standardization
During the object oriented programming session, Symbolics will present
some the developments going on there with respect to flavors. Xerox will
present their plans for CommonLoops testing using an implementation that
they have been working on. I expect that the discussions will focus more
closely on the methods and plans for evaluating the various proposals than
on the detailed technical merits of the proposals.
During the Windows discussion proposals can be presented along with
implementation plans.
For people who would like to make presentations, here are some guidelines:
1. Overhead or 35 millimeter slides are OK
2. Let me know that you want to make a presentation
as well as why a formal presentation is necessary.
3. If you want to include a handout, make at least 50 copies
(that's about 1 per group).
4. Try to limit your presentation to 30 minutes, maximum. I
will have a large hook.
-rpg-
∂26-Nov-85 0537 BSG@SCRC-STONY-BROOK.ARPA LET-IF
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 05:37:32 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 362815; Tue 26-Nov-85 08:35:48-EST
Date: Tue, 26 Nov 85 08:42 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: LET-IF
To: RSL@SCRC-STONY-BROOK.ARPA, GJC@MIT-MC.ARPA,
robbins%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM
In-Reply-To: <851125140843.3.RSL@QUETZLCOATL.SSF.Symbolics.COM>
Message-ID: <851126084235.2.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Mon, 25 Nov 85 14:08 PST
From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>
Date: Fri, 22 Nov 85 20:41:51 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Funny you should mention that, I'm considering flushing quite a few
special forms in the LMI system and replacing them with macros, LET-IF
is one, and the following definition seems right:
(defmacro let-if (pred bindings &body body)
(let ((f (gentemp "f")))
`(flet ((,f () ,@body))
(if ,pred (let ,bindings (,f)) (,f)))))
Unfortunately, this doesn't work if you want the bindings to be lexical
instead of special bindings. Consider:
(defun xor (a b)
(let-if a ((b (not b)))
b))
Unless B is special, this won't work using your scheme.
I can't imagine what LET-IF would mean with lexical variables
no matter what the implementation.
∂26-Nov-85 0805 GJC@MIT-MC.ARPA Mr Roberts vs Mr Rogers
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 08:03:30 PST
Date: Tue, 26 Nov 85 11:06:00 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: Mr Roberts vs Mr Rogers
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 25 Nov 85 10:40 EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MIT-MC.ARPA].733419.851126.GJC>
Too much jungle juice I suppose.
∂26-Nov-85 0940 GJC@MIT-MC.ARPA Mr Roberts vs Mr Rogers
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 08:03:30 PST
Date: Tue, 26 Nov 85 11:06:00 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: Mr Roberts vs Mr Rogers
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 25 Nov 85 10:40 EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MIT-MC.ARPA].733419.851126.GJC>
Too much jungle juice I suppose.
∂26-Nov-85 0959 gls@THINK-AQUINAS.ARPA LET-IF
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85 09:55:41 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2970; Tue 26-Nov-85 12:17:09-EST
Date: Tue, 26 Nov 85 12:15 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: LET-IF
To: BSG@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <851126084235.2.BSG@CONCORD.SCRC.Symbolics.COM>
Message-ID: <851126121559.6.GLS@FAUSTINUS.THINK.COM>
Date: Tue, 26 Nov 85 08:42 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Date: Mon, 25 Nov 85 14:08 PST
From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>
Date: Fri, 22 Nov 85 20:41:51 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Funny you should mention that, I'm considering flushing quite a few
special forms in the LMI system and replacing them with macros, LET-IF
is one, and the following definition seems right:
(defmacro let-if (pred bindings &body body)
(let ((f (gentemp "f")))
`(flet ((,f () ,@body))
(if ,pred (let ,bindings (,f)) (,f)))))
Unfortunately, this doesn't work if you want the bindings to be lexical
instead of special bindings. Consider:
(defun xor (a b)
(let-if a ((b (not b)))
b))
Unless B is special, this won't work using your scheme.
I can't imagine what LET-IF would mean with lexical variables
no matter what the implementation.
Date: Tue, 26 Nov 85 08:42 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Date: Mon, 25 Nov 85 14:08 PST
From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>
Date: Fri, 22 Nov 85 20:41:51 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Funny you should mention that, I'm considering flushing quite a few
special forms in the LMI system and replacing them with macros, LET-IF
is one, and the following definition seems right:
(defmacro let-if (pred bindings &body body)
(let ((f (gentemp "f")))
`(flet ((,f () ,@body))
(if ,pred (let ,bindings (,f)) (,f)))))
Unfortunately, this doesn't work if you want the bindings to be lexical
instead of special bindings. Consider:
(defun xor (a b)
(let-if a ((b (not b)))
b))
Unless B is special, this won't work using your scheme.
I can't imagine what LET-IF would mean with lexical variables
no matter what the implementation.
I can imagine: (let-if a ((b (not b))) (f b)) means
(if a (let ((b (not b))) (f b)) (f b)).
But in most such cases I should imagine
(let ((b (if a (not b) b))) (f b))
would do just as well (and result in better code), because a redundant
bindings of b to iself doesn't hurt in the lexical case (whereas it is
not allowed in the special case, as it would result in visibly different
semantics).
∂26-Nov-85 1128 hplabs!schumacher@hplabs.ARPA Amatuer Archivists.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 11:28:02 PST
Received: from hplabs.arpa by CSNET-RELAY.ARPA id a012324; 26 Nov 85 14:21 EST
Received: by hplabsd ; Tue, 26 Nov 85 11:21:21 pst
Date: Monday, November 25, 1985 15:17:03
From: schumacher@hplabs.arpa
Subject: Amatuer Archivists.
To: hplabs!gls%aquinas.think.com@csnet-relay.arpa
Cc: common-lisp <@csnet-relay.arpa:common-lisp@su-ai.arpa>
In-Reply-To: Your message of 26-Nov-85 12:15:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Is it really necessary to include the @i(entire) text of a previous msg to
reference it ? Guy's last msg was a particularly egregious example, starting out
with :
Date: Tue, 26 Nov 85 08:42 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Date: Mon, 25 Nov 85 14:08 PST
From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>
Date: Fri, 22 Nov 85 20:41:51 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
and then repeating it a SECOND time. Really folks, its not like we're all reading
mail with a line editor.
Lee
-------
∂26-Nov-85 1200 gls@THINK-AQUINAS.ARPA Amatuer Archivists.
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85 11:57:33 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 3017; Tue 26-Nov-85 15:00:28-EST
Date: Tue, 26 Nov 85 14:59 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Amatuer Archivists.
To: schumacher!hplabs@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 25 Nov 85 15:17-EST from schumacher@hplabs.arpa
Message-ID: <851126145919.0.GLS@FAUSTINUS.THINK.COM>
Da e: on ay, No mb r 5, 1 8 15:1 : 3
From s huma he @h abs.ar a
Is t eally ce sa y to i lude h @ ( ntire t xt o a pr ious m g o
r fe ence i ? Gu 's l s msg w s a a ticul l egr gi us xample s art ng ut
wi :
Date u , 26 N v 8 08:42 ST
Fr m: Ber ard S. Gre nb rg BS SCRC- ONY B OOK. R A
Dat Mon, 5 ov 5 4:0 PST
ro : R ch d Lam n < s @RUS I N SPA. y bol s.COM
Dat : Fri 22 No 85 20: 1: 1 E T
Fr m: Ge rge J. arret " < J @MIT M . RPA>
a d th n epeat n i SECO ime. R al folks ts ot ik we're ll
re di g mail w th a lin itor.
Lee
-------
Well, if we're all not using line editors, then having all that text
there shouldn't hurt. The redundant copy was, of course, an error on my
part (sorry). There is also somewhat of a tradition of allowing large
messages to build up occasionally. The likelihood of this happening is
inversely correlated with the seriousness of the subject matter.
Please note that, to save space, I have excerpted and condensed your
original message above.
--Quux
∂26-Nov-85 1202 gls@THINK-AQUINAS.ARPA Amatuer Archivists (again)
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85 12:02:17 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 3021; Tue 26-Nov-85 15:05:22-EST
Date: Tue, 26 Nov 85 15:04 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Amatuer Archivists (again)
To: schumacher!hplabs@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 25 Nov 85 15:17-EST from schumacher@hplabs.arpa
Message-ID: <851126150415.1.GLS@FAUSTINUS.THINK.COM>
On a more serious note, I receive anywhere between 20 and 100 messages a
day by electronic mail. Not infrequently there are three or four
distinct conversations on the common-lisp mailing list alone, and then
there are other mailing lists, as well as mail related to work I
actually get paid for. I often find it helpful to have some previous
context for each message. Maybe I tend to overdo it because I rely on
it more than others do. I'm sorry that I upset you.
--Guy
∂26-Nov-85 1202 KMP@SCRC-STONY-BROOK.ARPA DEFSTRUCT and predicates
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 12:02:26 PST
Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 363211; Tue 26-Nov-85 14:48:26-EST
Date: Tue, 26 Nov 85 14:49 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: DEFSTRUCT and predicates
To: ALAN@MIT-MC.ARPA, GLS@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <851126144928.6.KMP@DUPAGE.SCRC.Symbolics.COM>
The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed
convention for the formation of predicate names (CLtL, p71) by blindly
adding -P to the end of the symbol rather than adding just "P" when
there is no "-" in the base symbol.
∂26-Nov-85 1224 WHOLEY@C.CS.CMU.EDU DEFSTRUCT and predicates
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Nov 85 12:21:04 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Tue 26 Nov 85 15:20:05-EST
Date: Tue, 26 Nov 1985 15:20 EST
Message-ID: <WHOLEY.12162392973.BABYL@C.CS.CMU.EDU>
Sender: WHOLEY@C.CS.CMU.EDU
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: ALAN@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA, GLS@AQUINAS.THINK.COM
Subject: DEFSTRUCT and predicates
In-reply-to: Msg of 26 Nov 1985 14:49-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Tuesday, 26 November 1985 14:49-EST
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed
convention for the formation of predicate names (CLtL, p71) by blindly
adding -P to the end of the symbol rather than adding just "P" when
there is no "-" in the base symbol.
Yeah, at one point the language spec (or at least the language specifiers) said
that defstrict would "do the right thing" with defstruct predicates. This
decision was changed to the current one for some reason I don't recall. Note
that one can get the right effect by specifying the predicate name onesself.
As both an implementor and user of defstruct, I like the current situation -- I
don't think the naming conventions used by the system supplied functions should
be forced upon every single programmer.
Of course, Common Lisp follows a somewhat more complicated hueristic with
"-P"'ing things (e.g. Alpha-Charp). It's better that a program like defstruct
always do the same predictable dumb thing all the time than try to be clever
when it's going to be wrong occasionally.
--Skef
∂26-Nov-85 1418 NGALL@BBNG.ARPA Re: DEFSTRUCT and predicates
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 14:17:52 PST
Date: 26 Nov 1985 17:20-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: DEFSTRUCT and predicates
From: NGALL@BBNG.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]26-Nov-85 17:20:36.NGALL>
In-Reply-To: <WHOLEY.12162392973.BABYL@C.CS.CMU.EDU>
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: DEFSTRUCT and predicates
Message-ID: <WHOLEY.12162392973.BABYL@C.CS.CMU.EDU>
Date: Tuesday, 26 November 1985 14:49-EST
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed
convention for the formation of predicate names (CLtL, p71) by blindly
adding -P to the end of the symbol rather than adding just "P" when
there is no "-" in the base symbol.
Yeah, at one point the language spec (or at least the language specifiers) said
that defstrict would "do the right thing" with defstruct predicates. This
decision was changed to the current one for some reason I don't recall. Note
that one can get the right effect by specifying the predicate name onesself.
As both an implementor and user of defstruct, I like the current situation -- I
don't think the naming conventions used by the system supplied functions should
be forced upon every single programmer.
Of course, Common Lisp follows a somewhat more complicated hueristic with
"-P"'ing things (e.g. Alpha-Charp). It's better that a program like defstruct
always do the same predictable dumb thing all the time than try to be clever
when it's going to be wrong occasionally.
--Skef
--------------------
The only complexity in the CL "-P" heuristic is dealing with qualified
predicates such as string-(lessp). Since defstruct created predicates
will ALWAYS be suffixing data-type names (NEVER existing predicate
names), defstruct can safely use the simple hyphenation heuristic,
i.e., if the data-type name is hyphenated, add "-P", otherwise add
"P". Can anyone think of counter-examples?
I think defstruct SHOULD obey the CL convention. At the very least,
it should be documented that it is BREAKING the convention.
-- Nick
∂26-Nov-85 1528 WHOLEY@C.CS.CMU.EDU DEFSTRUCT and predicates
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Nov 85 15:28:09 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Tue 26 Nov 85 18:27:46-EST
Date: Tue, 26 Nov 1985 18:27 EST
Message-ID: <WHOLEY.12162427138.BABYL@C.CS.CMU.EDU>
Sender: WHOLEY@C.CS.CMU.EDU
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: DEFSTRUCT and predicates
In-reply-to: Msg of 26 Nov 1985 17:20-EST from NGALL at BBNG.ARPA
Date: Tuesday, 26 November 1985 17:20-EST
From: NGALL at BBNG.ARPA
The only complexity in the CL "-P" heuristic is dealing with qualified
predicates such as string-(lessp). Since defstruct created predicates
will ALWAYS be suffixing data-type names (NEVER existing predicate
names), defstruct can safely use the simple hyphenation heuristic,
i.e., if the data-type name is hyphenated, add "-P", otherwise add
"P". Can anyone think of counter-examples?
How about:
(defstruct person
mom
dad
kids
shoe-size)
(defstruct (space-person (:include person))
planet-of-birth
number-of-eyes)
Space-Person-P (or Space-Personp) is what you call a "qualified predicate."
I think defstruct SHOULD obey the CL convention. At the very least,
it should be documented that it is BREAKING the convention.
Yes, such a note in the manual would be worthwhile.
--Skef
∂26-Nov-85 2233 TIM@MIT-MC.ARPA Amatuer Archivists (again)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 22:33:46 PST
Date: Wed, 27 Nov 85 01:36:13 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Amatuer Archivists (again)
To: common-lisp@SU-AI.ARPA
cc: schumacher!hplabs@CSNET-RELAY.ARPA, gls@THINK.COM
Message-ID: <[MIT-MC.ARPA].734507.851127.TIM>
I sympathize with those of you who have short terminals and have to wade
through pages and pages of "context." (About 1/2 of my terminal's ram is
shot, so mine is about 14 lines tall). But I also agree with Steele.
Perhaps the problem lies with the conventions we use for replying to mail.
If, instead of putting the reply at the end of the message (as is so easy to
do when using BABYL, RMAIL and ZMAIL), we put our reply at the beginning, we
could have the best of both worlds: Immediacy and Context.
Tim
Date: Tue, 26 Nov 85 15:04 EST
From: Guy Steele <gls at THINK-AQUINAS.ARPA>
On a more serious note, I receive anywhere between 20 and 100 messages a
day by electronic mail. Not infrequently there are three or four
distinct conversations on the common-lisp mailing list alone, and then
there are other mailing lists, as well as mail related to work I
actually get paid for. I often find it helpful to have some previous
context for each message. Maybe I tend to overdo it because I rely on
it more than others do. I'm sorry that I upset you.
--Guy
∂27-Nov-85 1901 mips!escargot.earl@glacier lexical scope and dynamic extent
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 19:01:49 PST
Received: by glacier with Sendmail; Wed, 27 Nov 85 19:01:17 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
id AA11694; Wed, 27 Nov 85 18:32:27 pst
Received: by escargot.UUCP (4.12/4.7)
id AA15071; Wed, 27 Nov 85 18:31:55 pst
Date: Wed, 27 Nov 85 18:31:55 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8511280231.AA15071@escargot.UUCP>
To: common-lisp@su-ai.ARPA
Subject: lexical scope and dynamic extent
Some entities in the language are described as having lexical scope
and dynamic extent, which means that they can be refered to after
they're gone. Do any of the implementations have good ways of
detecting such things? Here's a nasty one:
(defun foo ()
(tagbody
l (return-from foo #'(lambda () (go l)))))
(funcall (foo))
If you type this at various implementations, what do you get?
∂27-Nov-85 2011 BROOKS%MIT-OZ@MIT-MC.ARPA Re: lexical scope and dynamic extent
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 20:11:13 PST
Date: Wed 27 Nov 85 23:11:34-EST
From: "Rodney A. Brooks" <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: lexical scope and dynamic extent
To: mips!escargot.earl@SU-GLACIER.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8511280231.AA15071@escargot.UUCP>
Message-ID: <12162740965.44.BROOKS@MIT-OZ>
In Lucid's SUN Common Lisp 1.0, compiled foo, you get
>>Error: A go to one of (L) occured from within an out of scope closure
Maybe the English needs a little work...
Date: Wed, 27 Nov 85 18:31:55 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8511280231.AA15071@escargot.UUCP>
To: common-lisp@su-ai.ARPA
Subject: lexical scope and dynamic extent
Some entities in the language are described as having lexical scope
and dynamic extent, which means that they can be refered to after
they're gone. Do any of the implementations have good ways of
detecting such things? Here's a nasty one:
(defun foo ()
(tagbody
l (return-from foo #'(lambda () (go l)))))
(funcall (foo))
If you type this at various implementations, what do you get?
-------
∂28-Nov-85 1051 ACUFF@SUMEX-AIM.ARPA Re: lexical scope and dynamic extent
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 Nov 85 10:51:25 PST
Date: Thu 28 Nov 85 10:51:07-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Re: lexical scope and dynamic extent
To: mips!escargot.earl@SU-GLACIER.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8511280231.AA15071@escargot.UUCP>
Message-ID: <12162901082.56.ACUFF@SUMEX-AIM.ARPA>
In Explorer Common Lisp you get:
>>>ERROR: GO tag L is not defined or is no longer valid
which seems reasonable given the statment near the top of pg. 131 of
CLtL, "Once a tagbody construct has been exited, it is no longer legal
to go to a tag in its body."
I think you may be confusing dynamic extent and indefinite extent.
An entity with dynamic extent (in this case the tag) continues to
exist only as long as the form that establishes it (the tagbody),
while entities with indefinite extent continue to exist as long as
there is a reference to them.
-- Rich
-------
∂30-Nov-85 1245 RPG ANSI/ISO
To: quinquevirate@SU-AI.ARPA
I had hoped to have gotten the full story behind what I'm about to
relate to you before I had to send this message, but time before the
CL meeting is short, and I'll have to remember the story as best I can.
ISO met some time in September or October. Steve Squires sent his friend,
Bob Mathis, who was part of the Ada ISO committee (?). The meeting was in
Paris, and Steve was concerned that `something funny' would happen. As it
turned out, France proposed to propose a Lisp standard and volunteered to
head the Lisp committee. Being primed, Mathis stepped in and got himself
appointed head of the ad hoc committee to study the question of an ISO
standard Lisp.
Squires put Mathis in touch with me to start the wheels in motion for the
Common Lisp group to do something about France's bid. I have heard rumors
of French disappointment with CL (mostly voiced by Jerome Chailloux).
I believe that we may have to respond to this challenge somehow or other,
and possibly it requires us to start down the true standardization road.
Not having seen this road before, it doesn't scare me, but I gather it scares
many others. Mathis is coming to the meeting, and we can discuss the issues
more fully with him.
∂30-Nov-85 1257 RPG More on the CL meeting
To: quinquevirate@SU-AI.ARPA
Would you folks be interested in a caucus before the meeting to talk
about what you think will go on? We can caucus via this medium, if you
like.
Having seen how these meetings tend to go, I'd like to recommend the
style of meeting in which people are recognized to hold the floor for
some length of time, yielding in formal ways to others. This would
be along the normal lines of parliamentary rules. I want to keep the
randomness to a minimum, and I can easily imagine someone like Carrette
and Jonl going at it with each other - this I want to avoid.
The three proposals for charter that seem viable are the Fahlman
full-blown proposal of Jan 21, the Fahlman mimimalist proposal of Feb 18,
and the Fahlman Common Lisp Club idea. This last idea, if I may present
it, is for us to form a Common Lisp Organization as a private `club,'
with rules and bylaws, and curious document called the Common Lisp Book.
People may join the club and agree to live by the Book, but CL is no more
standard than that. Fahlman's idea is a little less silly than that sounds,
in that it would be a legal organization with some instrument of `incorporation'
of some sort.
I propose we put these proposals on the table for discussion and record
the opinions we get at the meeting.
One phenomenon I'd like to point out to you as existing, but about which you
might not be aware, is that a large fraction of the programming-related
world that knows of Common Lisp, believes that there is a Common Lisp Group
that makes decisions and holds a standard somewhere. People are constantly
calling me and asking when the Common Lisp Group will decide this, that, or
the other thing. People tend to identify that group with us. Perhaps it's
time for us to demonstrate a little more leadership than we have in the past.
-rpg-
∂01-Dec-85 1219 DLW@SCRC-STONY-BROOK.ARPA lexical scope and dynamic extent
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 12:19:26 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364776; Sun 1-Dec-85 15:17:00-EST
Date: Sun, 1 Dec 85 15:23 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: lexical scope and dynamic extent
To: mips!escargot.earl@SU-GLACIER.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8511280231.AA15071@escargot.UUCP>
Message-ID: <851201152340.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
In the Symbolics system, interpreted, you get
>>Error: The GO tag L is no longer dynamically active
Compiled, you get a less-comprehensible error message:
>>Error: Attempt to %UNWIND-INTO-FRAME-AT-PC to a frame not running a
compiled function
In both cases, the system has detected that something's wrong. In the
latter case, it goes to look for the tag, and finds an interpreted frame
where it expected a compiled frame, because the outer frame is gone. To
improve the error message, we'd probably have to add some more
debugging-info (debugging-info is extra structure that lives with a
compiled code object to help the system create error messages and to
help various debugging tools figure out what's happening, among other
things). It wouldn't be particularly hard.
∂01-Dec-85 1645 NGALL@BBNG.ARPA Re: DEFSTRUCT and predicates
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 16:44:32 PST
Date: 1 Dec 1985 19:47-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: DEFSTRUCT and predicates
From: NGALL@BBNG.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA] 1-Dec-85 19:47:09.NGALL>
In-Reply-To: <WHOLEY.12162427138.BABYL@C.CS.CMU.EDU>
Date: Tue, 26 Nov 1985 18:27 EST
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Subject: DEFSTRUCT and predicates
In-Reply-To: Msg of 26 Nov 1985 17:20-EST from NGALL at BBNG.ARPA
Message-ID: <WHOLEY.12162427138.BABYL@C.CS.CMU.EDU>
Date: Tuesday, 26 November 1985 17:20-EST
From: NGALL at BBNG.ARPA
The only complexity in the CL "-P" heuristic is dealing with qualified
predicates such as string-(lessp). Since defstruct created predicates
will ALWAYS be suffixing data-type names (NEVER existing predicate
names), defstruct can safely use the simple hyphenation heuristic,
i.e., if the data-type name is hyphenated, add "-P", otherwise add
"P". Can anyone think of counter-examples?
How about:
(defstruct person
mom
dad
kids
shoe-size)
(defstruct (space-person (:include person))
planet-of-birth
number-of-eyes)
Space-Person-P (or Space-Personp) is what you call a "qualified predicate."
Hmmm. I think I disagree. I don't think Space-Person-P falls under
the CL definition of "qualified predicate":
1. The rationale for for NOT hyphenating the "P" in "STRING-LESSP" is
that it would "incorrectly imply that it is a predicate that tests for
a kind of object called a STRING-LESS." This is exactly what we WANT
to imply in the case of SPACE-PERSON; so the predicate should be
SPACE-PERSON-P.
2. Your definition by example would require that SIMPLE-STRING-P
become SIMPLE-STRINGP, BIT-VECTOR-P become BIT-VECTORP, etc., since
STRINGP, VECTORP, etc., are already predicates.
3. In my opinion, the only predicates that retain their
"P"s "as is" are predicates such as lessp, greaterp, equalp, i.e.,
non-type-predicates. And these are the kind of predicate that
defstruct will never have to deal with.
-- Nick
∂01-Dec-85 1756 Moon@SCRC-STONY-BROOK.ARPA More on the CL meeting
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 17:56:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364899; Sun 1-Dec-85 20:53:51-EST
Date: Sun, 1 Dec 85 20:52 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: More on the CL meeting
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: The message of 30 Nov 85 15:57-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851201205239.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 30 Nov 85 1257 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
Would you folks be interested in a caucus before the meeting to talk
about what you think will go on? We can caucus via this medium, if you
like.
I'm busy but willing to listen to mail. I have not planned to participate in
the charter discussion at all.
....One phenomenon I'd like to point out to you as existing, but about which you
might not be aware, is that a large fraction of the programming-related
world that knows of Common Lisp, believes that there is a Common Lisp Group
that makes decisions and holds a standard somewhere. People are constantly
calling me and asking when the Common Lisp Group will decide this, that, or
the other thing. People tend to identify that group with us. Perhaps it's
time for us to demonstrate a little more leadership than we have in the past.
Does this mean that a fourth proposal should be put on the table, that anything
to which the five people on the title page of the manual agree among themselves
is the law and everyone else has to accept it?
∂02-Dec-85 0815 FAHLMAN@C.CS.CMU.EDU ANSI/ISO
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85 08:15:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 11:11:42-EST
Date: Mon, 2 Dec 1985 11:11 EST
Message-ID: <FAHLMAN.12163920553.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: quinquevirate@SU-AI.ARPA
Subject: ANSI/ISO
I'm not convinced that the ISO thing is any kind of threat to the spread
of Common Lisp. Suppose we do nothing. The French get ISO to form a
committee on Lisp, seize control of it, and produce some silly standard
based on Le Lisp. My guess is that all of the major U.S. manufacturers,
plus most manufacturers in Japan and some in Europe (Siemens, for
example) will ignore this and continue to develop Common Lisp and things
based on Common Lisp.
If that's how it works out, how does the ISO business hurt anything? Is
there really a chance that anyone outside of the EEC would follow the
ISO standard, or that it would lead to a serious split if some Europeans
did decide to fillow ISO? Some of the Europeans will undoubtedly find
some reason to split off anyway, just to keep their record for chronic
wrong-headedness intact. Might European governments require ISO Lisp,
even though that shuts them off from all of the best technology? I
suppose that an ISO standard would give the French an excuse to split
off by themselves while saying that they are right and everyone else is
wrong, since only they are adhering to the ISO standard, but the French
do this all the time anyway and the rest of the world ignores them. If
we're careful to lend no credibility to the ISO thing, it should just
disappear as so many silly standards have in the past.
So unless someone can make a case for why this is important, I say we
should just ignore it, after maybe a bit of discussion at the meeting.
-- Scott
∂02-Dec-85 0822 FAHLMAN@C.CS.CMU.EDU More on the CL meeting
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85 08:22:17 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 11:22:11-EST
Date: Mon, 2 Dec 1985 11:22 EST
Message-ID: <FAHLMAN.12163922524.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: quinquevirate@SU-AI.ARPA
Subject: More on the CL meeting
In-reply-to: Msg of 30 Nov 1985 15:57-EST from Dick Gabriel <RPG at SU-AI.ARPA>
I am preparing some thoughts on charter stuff that I will send out later
today.
It would be helpful if one of the Boston people (
∂02-Dec-85 0828 DLW@SCRC-STONY-BROOK.ARPA More on the CL meeting
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 08:28:43 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 365216; Mon 2-Dec-85 11:23:12-EST
Date: Mon, 2 Dec 85 11:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: More on the CL meeting
To: Moon@SCRC-STONY-BROOK.ARPA
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: <851201205239.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851202112950.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sun, 1 Dec 85 20:52 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Does this mean that a fourth proposal should be put on the table, that anything
to which the five people on the title page of the manual agree among themselves
is the law and everyone else has to accept it?
I didn't get the impression that RPG was suggesting anything quite that
extreme. I, too, am aware that lots of people assume that there is a
"Common Lisp committee" out there somewhere, and that things are under
some kind of control. Right now, of course, that's not true; we don't
even have a forum for resolving ambiguities in the manual.
Big meetings such as the upcoming one can go on for a long time and not
produce any results, and if that happens at this meeting, not only will
we all feel like we wasted our time, but we will probably give up on
ever trying to have such a meeting again, because we'll be convinced
that it's hopeless. So it's important that this meeting get something
done, and give us all the feeling that progress is being made. The
question is how to help assure that the meeting really is effective.
My interpretation of what RPG was suggesting is that one way to help
make sure something happens is for us to show some leadership. We hope
that if we can form a core group (a) with a more or less consistent
opinion, and (b) with our implied prestige, then this might form a seed
around which other opinions could crystalize. If it turns out that a
lot of people are opposed to what the five of us might feel, then of
course we don't take any special kind of precedence. What we're trying
to prevent is a situation in which there are several alternatives, some
of which are better than doing nothing at all, but nothing at all gets
done because there's no way to build a concensus. At least that's my
interpretation.
∂02-Dec-85 1051 FAHLMAN@C.CS.CMU.EDU as I was saying...
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85 10:51:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 13:51:21-EST
Date: Mon, 2 Dec 1985 13:51 EST
Message-ID: <FAHLMAN.12163949688.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: quinquevirate@SU-AI.ARPA
Subject: as I was saying...
The last message went off half-cocked. I was trying to say two things:
1. I have some thoughts on the charter stuff that I will try to cast
into some usable form and get off to the rest of you later today.
2. It would help if someone in Boston (maybe Guy) were to investigate
what effect this hotel strike is likely to have on the upcoming
conference. If by the end of this week it looks like the hotel we are
meeting in is down, we might need to cancel this whole thing.
-- Scott
∂02-Dec-85 1054 RPG ANSI/ISO and Hotel Strike
To: quinquevirate@SU-AI.ARPA
I'm simply not sure whether or not having an ISO standard Lisp
makes any difference, either in general or anymore. It seems
we are at the crossroads as to whether Common Lisp remains the
`property' of us (the CLG at large) or whether it is part of the
world at large.
There are two possible courses: Leave standardization alone, and
go after it.
People mention horror stories. So far the people who have done so
are people who would seem to be otherwise afraid of political
battle. I'll buy a lobster dinner at Legal for any one of you who
can tell me a real horror story that actually happened and which
scares me in some way. If we ignored all standardization, that makes
a statement against official standards and also tells the world
we are above the normal hue and cry. Is that what we want?
If we go for standardization, we should aim to avoid to the supposed
horror scenarios and thereby show the world that it can be done. Then
we'll be able to tell our friends anti-horror stories about the
standardization battle.
Suppose we start down the ISO route and it gets bad, can't we simply
drop it or lose interest enough so that it isn't a hassle for us anymore?
In other words, what is the downside of ignoring the standardization
issue? If there isn't one, why did Squires send his stooge to Paris to
prevent us from losing the edge?
I don't want the reason for us not going with ANSI and ISO to be:
Gee, I heard a horror story about something or other and I don't want
us involved with that; plus, we're too strong for anyone to make a
dent in our position. ...Unless we know the facts about what can happen
and how those events are unimportant or reparable.
About the hotel strike: My Boston operatives are looking into it
even now. The belief is that it will not affect us one way or the
other, but we will know later today or tomorrow.
-rpg-
∂02-Dec-85 1135 FAHLMAN@C.CS.CMU.EDU ANSI/ISO and Hotel Strike
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85 11:34:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 14:28:20-EST
Date: Mon, 2 Dec 1985 14:28 EST
Message-ID: <FAHLMAN.12163956376.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: rpg@SU-AI.ARPA
Cc: quinquevirate@SU-AI.ARPA
Subject: ANSI/ISO and Hotel Strike
In-reply-to: Msg of 2 Dec 1985 13:54-EST from Dick Gabriel <RPG at SU-AI.ARPA>
Some further thoughts on the ISO thing:
I'm simply not sure whether or not having an ISO standard Lisp
makes any difference, either in general or anymore. It seems
we are at the crossroads as to whether Common Lisp remains the
`property' of us (the CLG at large) or whether it is part of the
world at large.
Maybe the question is whether Common Lisp remains the property of the
active Lisp community (largely in the U.S.) or whether it is taken over
by European fanatics who don't like Lisp anyway and who have nothing
better to do than to play political games with committees.
There are two possible courses: Leave standardization alone, and
go after it.
Leaving ISO and ANSI alone is not the same as leaving "standardization"
alone. The IBM/PC is a standard, for example. Official standardization
is just one kind of standardization, and is generally the weakest kind.
If we ignored all standardization, that makes
a statement against official standards and also tells the world
we are above the normal hue and cry. Is that what we want?
Standards are fine for plugs, character codes, and floppy-disk formats.
I don't think that anything as large and complex (not to mention
political) as Common Lisp has ever been successfully standardized by an
official committee of this sort. Big things get standardized by brute
force and a committee maybe blesses them later. Indeed, Common Lisp is
already somewhat unique among huge systems in that the standard did not
come from one single company as a fait accompli, but was discussed by
many participants. I think the ARPANET was a key ingedient in making
this possible, and that the ISO machinery is unsuitable. Can you
imagine doing what we did if everyone had to fly off to face-to-face
meetings twice a year and to communicate by international airsnail at
other times? Can you imagine the process going smoothly in the future
under those conditions, even now that we all agree on the lowest-level
stuff?
Suppose we start down the ISO route and it gets bad, can't we simply
drop it or lose interest enough so that it isn't a hassle for us anymore?
In other words, what is the downside of ignoring the standardization
issue?
I see two downsides: first, we've got work still to do in
standardizations and the last thing we need is to saddle ourselves with
a lot of extraneous bureaucratic restrictions on how this work will be
done; second, if the ISO process gets our participation and produces
something close to Common Lisp but not close enough to satisfy us, then
we've created confusion as to which is the "real" Common Lisp. A
strictly French effort in which they do their own thing would not
confuse the issues in this way. Getting ISO to approve Common Lisp
exactly as we define it is probably not possible (am I wrong about
this?), and a near miss is the worst possible outcome.
If someone wants to do all the work to capture the ISO process and
believes that we can either get true Common Lisp approved or walk out
cleanly, that's OK with me, but it's a big effort for dubious gain in my
opinion.
-- Scott
∂02-Dec-85 1153 RPG Exposing My Machiavellan Tendencies
To: quinquevirate@SU-AI.ARPA
Suppose France gains control of the ISO process, and suppose they
do something that is the direct marriage of what they want and Common Lisp.
I think this is both the most likely outcome and the best outcome we
can expect. They want a subset - at least that's what Chailloux wants.
What we end up with as an ISO standard is a smallish subset of Common Lisp.
France does something in computer science, and they do build/distribute/sell
computers. So what does someone in Europe do to be `safe' when writing
Lisp code? He codes in the intersection, which happens to be the standard.
What does someone in the US do when he codes for US machines that are
used in Europe and when the code will be shipped there? He codes in the
intersection.
This creates confusion in a lot of peoples's minds. What I would like
to propose is that we start down the ISO path, in order to block the
thrust of the French bid. Then we delay on the official front while
continuing on on the informal front as we have been. Eventually we can
make the right decision, or perhaps we can delay until it is clear no
decision is needed.
The idea is to shield our normal activities from the potential irritation
that a French ISO bid could cause.
-rpg-
∂02-Dec-85 1209 FAHLMAN@C.CS.CMU.EDU Exposing My Machiavellan Tendencies
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85 12:09:18 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 15:09:11-EST
Date: Mon, 2 Dec 1985 15:09 EST
Message-ID: <FAHLMAN.12163963846.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: quinquevirate@SU-AI.ARPA
Subject: Exposing My Machiavellan Tendencies
In-reply-to: Msg of 2 Dec 1985 14:53-EST from Dick Gabriel <RPG at SU-AI.ARPA>
OK, the best outcome would be to get ISO to agree to accept Common Lisp
is is and to track changes. Not feasible.
The second best outcomes (a tie) are either to screw up the ISO process
so that nothing comes out of it, or to get the French to do something so
different from Common Lisp that nobody will injure himself by trying to
straddle the fence.
The bad case is that the ISO thing ends up looking very much like Common
Lisp, but that it is different enough (perhaps by being a subset) to
cause real trouble, confusion, and to split the Common Lisp market
because of that.
The worst possible case is that we cooperate a little bit with this, but
end up in the "bad case" anyway, because then it lends legitimacy to
this mutant offspring.
So we do have something to talk about: how do we prevent the bad case
without wasting a lot of everyone's valuable time and without falling
into the worst possible case. But we can't talk about trying to stall
this process in public, so we have to pretend that if we participate at
all we are going for full acceptance of Common Lisp. A tricky business.
-- Scott
∂02-Dec-85 1250 DLW@SCRC-QUABBIN.ARPA ANSI/ISO
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 12:50:27 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 224838; Mon 2-Dec-85 15:46:53-EST
Date: Mon, 2 Dec 85 15:54 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: ANSI/ISO
To: Fahlman@C.CS.CMU.EDU, quinquevirate@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12163920553.BABYL@C.CS.CMU.EDU>
Message-ID: <851202155411.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
I agree with what you say about ISO. We should spend at least a little
time at the meeting, though, finding out just what is the worst that
would happen if ISO goes its own way. In other words, we should get
answers to the questions you asked in your mail.
∂02-Dec-85 1622 DLW@SCRC-STONY-BROOK.ARPA ANSI/ISO
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 16:22:26 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 365743; Mon 2-Dec-85 18:36:33-EST
Date: Mon, 2 Dec 85 18:43 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: ANSI/ISO
To: quinquevirate@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12163956376.BABYL@C.CS.CMU.EDU>
Message-ID: <851202184313.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Hmm. I sympathize with all the points I've heard. It's a hard
question.
Let me toss in one more anti-official-standards point: because there
are so many standards organizations running around, we have to worry
about whether there might be an ISO standard, an ANSI standard, an IEEE
standard, a CCITT standard, and so on. The network protocol world is
the canonical example of this problem. The latest things I've been
hearing about is a new protocol that's basically a lot like IP/TCP, but
incompatible, called MAP, which is a General Motors standard (no
kidding) that has become popular in the factory-automation world. The
world of networking also has HDLC, SDLC, and LAPB, which are nearly
identical, but not quite, and sponsored by different organizations, one
of which is IBM.
In light of this, I am particularly worried by Scott's poing that we
might end up with "original CL" and "ISO CL", which are pretty close but
not quite the same.
I am tempted to add "not the same, because some random French LeLisp
people wanted to have some say in the standard, so they changed the
order of arguments to some functions randomly just so that they could
feel that they were among the creators of the standard." Everyone wants
to be one of the creators of the standard. For example, T.I. has been
broadly advertising that they were heavily involved in the design of
Common Lisp. I hate the idea of opening it up again just so that more
people can wear "I created Common Lisp" buttons.
There's no point in having a language standard if it is in a continual
state of redesign. While I don't know any particular horror stories, I
do know that these things typically take significant amount of time,
like several years, before they come out with standards. I'd hate to
have to say "wait, world, there isn't actually any Common Lisp standard
yet, wait for the ISO committee." This is a fast-moving field; we
really cannot wait that long.
Now, in the past, we've mentioned having a "Common Lisp 89" or whatever,
a second generation language standard to come out in several years.
Perhaps if we (or the new charter group) still believe that, we should
consider dealing with ISO and/or ANSI.
I understand Steele has been involved in the ANSI C committee; perhaps
he could comment on all this in light of his experience.
∂02-Dec-85 1738 Moon@SCRC-STONY-BROOK.ARPA Hotel Strike
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 17:38:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 365784; Mon 2-Dec-85 19:33:12-EST
Date: Mon, 2 Dec 85 19:32 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Hotel Strike
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: The message of 2 Dec 85 13:54-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851202193211.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 02 Dec 85 1054 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
About the hotel strike: My Boston operatives are looking into it
even now. The belief is that it will not affect us one way or the
other, but we will know later today or tomorrow.
It was settled yesterday. The union members vote on it later this week,
and it is predicted that they will approve the agreement that the union
leaders and management agreed to, but I suppose you could always worry
that they won't.
∂02-Dec-85 2037 FAHLMAN@C.CS.CMU.EDU Charter stuff
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85 20:37:21 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 23:37:16-EST
Date: Mon, 2 Dec 1985 23:37 EST
Message-ID: <FAHLMAN.12164056344.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: quinquevirate@SU-AI.ARPA
Cc: fahlman@C.CS.CMU.EDU
Subject: Charter stuff
In his recent mail, Dick Gabriel suggested that there are three
proposals we might want to discuss: the "full-blown" proposal, the
"minimalist" proposal, and the "club" proposal. I see the issues a bit
differently, I guess. Basically, I see three almost orthogonal issues
and one big problem.
Issue 1: Do we want an organization to do only what is absolutely
necessary, or do we want it to provide a range of services to the
community?
This is the difference between the "full blown" and "minimalist"
proposals. A minimal organization would basically just provide a
technical committee, some way of electing the committee, a communication
channel for questions, discussion, and decisions, a legal entity that
can own those things that belong to "the Common Lisp community". The
other services that a "full blown" organization might provide would
include keeping the archives in some sort of order, maintaining and
distributing a public-domain library including such things as the Spice
Lisp and Hemlock sources, perhaps a newsletter, communication by mail to
those not on electronic networks, maintaining and distributing a
validation suite, maybe running the actual validations, and so on.
To provide these services would require a full-time employee or two and
would cost maybe $150K/year if done within some existing organization
(sharing office space and some other facilities). In the past, CMU has
done some of this stuff, others have done some, and some important
things have just not been done. I'm pretty sick of dealing with this
stuff at CMU without adequate administrative support, so if nothing else
is set up, things are soon going to get much worse -- no more tapes sent
to people, etc. If the Common Lisp association does these things, we
will have to raise big bucks either through corporate dues or grants.
At one point the DARPA folks suggested that they would give a contract
to ISI to do these things, but nothing seems to be happening on that
front and ISI doesn't seem to have much enthusiasm for the task. Maybe
this idea can be resurrected; if so, I think a minimalist organization
is preferable to a heavy one.
Issue 2: Who decides who is to decide?
We probably want a rather small technical committee that would operate
by discussing issues with the community at large (that part of it
reachable by netmail, anyway) but that would then be able to make
decisions about the language without having to get 100% consensus.
Everyone could discuss (cajole, threaten, whatever) but only a few
people would actually make the decisions. The question is how we elect
a technical committee.
The obvious move is to let anyone join the organization as an individual
member who wants to pay the dues (not too much, maybe $20/year), and to
let these individual members elect the technical committee -- one
member, one vote. The big problem here is to ensure that this
democratic process is not subverted (e.g. by some company packing the
membership by signing up all their employees) and that an influx of
people from some odd corner of the community does not carry Common Lisp
off in directions that the original community and the major
manufacturers do not want to see it go in. I can imagine an invasion of
hobbyist types, for example, who might decide that the most important
thing is to be sure that Common Lisp fits easily into 640K of memory.
Such people should have a voice, but it is not clear that every random
hobbyist who has paid his $20 should have as large a voice as someone
who is using Lisp in a serious professional way.
So the real question is, if we go with a democratically elected
technical committee, whether we need some extra machinery to keep
the language true to its original goals. Some possible responses:
A. This might once have been a problem, when major groups were trying to
bend Common Lisp to be closer to their old Lisps, but is no longer an
issue.
B. The technical committee should be elected, but the manufacturers and
other corporations should have a veto power of some sort. This was the
genesis of my earlier proposal that we have corporate members (filtered
by their willingness to pay big dues) and that 2/3 or 3/4 of these
corporate members are sufficent to veto actions by the technical
committee. The very existence of this veto would make it useless for
any one company to try to pack the membership and take over the
technical committee.
C. We could try to write into the organization's constitution all of
those things that we never want anyone to change. This has always
struck me as infeasible.
D. We could pick a few well-known people who have been involved in the
Common Lisp effort from the start and make them a sort of "supreme
court". For the first few years of the organization's existence, these
people (by a 2/3 vote or something like that) would have the right to
veto any changes that they view as contrary to the original goals and
ongoing well-being of the language. There is a problem of how to
get this set up -- if the initial supreme court is elected
democratically, all of the same potential problems come up here as with
the technical committee. See below for one possible solution.
Issue 3: How do we bootstrap such an organization?
I think that we are going to have a hell of a time getting consensus on
any detailed plan for an organization at the Boston meeting or via the
network. In a group that large and diverse, there will always be
somebody who wants to quibble at length about something. And if we
don't have either a consensus or a pre-existing constitution, how do we
settle these issues? Who gets to vote? Who has a veto? The Boston
meeting will not fairly represent the community as a whole because of
geography -- the local companies will have many more people there.
One thought I have had (RPG calls it the "club" proposal, but I think
that this is bad PR), is that a few of us get together and form an
organization ourselves. We would do our best to come up with a plan
that the community will approve of, and we can ask individuals or the
whole community for advice, but in the end we make the decisions. "We"
in this case is the five of us, plus any others we decide to invite into
the process at this stage. We elect an initial set of officers and a
technical committee. Guy would agree that future editions of his book
would reflect Common Lisp as defined by this organization. Then, once
this is all in place, we open up membership to anyone who wants to join.
Now, this organization has no power or authority at the start, except
what it derives from the "big names" who are associated with. But if a
lot of companies join and announce that they intend to follow this
organization's definition of Common Lisp, then it quickly becomes the de
facto setter of standards. If anyone doesn't like some detail of the
way we set up the organization, they can stay out and pout, but they
can't induce paralysis.
What gives us the right to go off and set this up the wy we want to?
Well, everyone has the same right, but our attempt to do this might
stick because of our stature in the Common Lisp community. And this is
not so unusual; most new organizations start this way, with a small
nucleus of people who decide to set something up. As I understand it,
AAAI came about when a few of the major people in the field of AI
decided that there ought to be a national AI organization and just went
off and created it. By the time most of us heard about this
orgainzation, it was a fait accompli, with a constitution and a set of
officers already in place.
Anyway, this is something to think about. I don't see any good
alternative. We don't have to be sneaky about this. We can ask the
people at the meeting what they think about this, which is not the same
as asking their permission.
This is orthogonal to the heavy/lightweight issue, except that we
obviously couldn't offer many services until we have some money coming
in. It is also orthogonal to the issue of whether we need to build in
some sort of stabilization mechanism, except that it gives us an easy
way to create a "supreme court" effect if we want to. The idea is that
we would elect an initial technical committee before we open up
membership to the world at large, and we install a trustworthy set of
people for fairly long terms. The new membership could elect new people
as vacancies open up, but even in the worst case it would take several
years before new people would outnumber our initial handpicked group.
Probably this is all the stability we need.
MAJOR PROBLEM: how can we protect the people prominently involved in
this organization from harassment by lawyers.
Sooner or later, some decision is going to go against some company that
likes to use the legal system as a weapon. Or maybe some group on the
outside decides to try to destroy Common Lisp by suing the organization
and the visible people in it. Even if the lawsuit is totally without
merit, a large company can destroy a random private citizen by forcing
him to spend a fortune on legal fees. Unless the organization has both
the commitment and the resources to protect the people involved from
lawsuits, I for one am not going to expose myself to that kind of risk.
(CMU has some sort of indemnification policy for its faculty, but it is
vague and probably worthless. I don't think it would cover something
this far from my "usual" duties.) Even to get some lawyer to explain to
us what the risks and possible defenses really are would cost quite a
bit. I'm not sure how big a war chest would be adequate, or whather
there is some way to insure against this kind of threat, or whether some
company or other organization would be able to shield us while we set up
some sort of organization.
Anyway, this has to be dealt with BEFORE we do anything else, and
especially before we try to start an organization by ourselves as
individuals. I don't know what to do about this. Ever since Beau Sheil
and Xerox started making legal threats last year I've been really afraid
of this. I've got no access to lawyers to discuss this problem unless I
spend my own money, which I'm not eager to do. It's a shame that this
kind of nonsense has to enter into our considerations, but that's the
way it is. Ideas?
-- Scott
∂03-Dec-85 1706 hplabs!snyder@hplabsd manual bug (index)
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 17:06:28 PST
Received: by hplabsd ; Tue, 3 Dec 85 17:04:55 pst
Date: Tuesday, December 3, 1985 16:54:15
From: snyder@hplabsd
Subject: manual bug (index)
To: common-lisp@su-ai
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
In case it's not been noticed before,
the function KEYWORDP appears in the index as KEYWORD.
-------
∂03-Dec-85 1719 hplabs!snyder@hplabsd keywords
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 17:19:01 PST
Received: by hplabsd ; Tue, 3 Dec 85 17:17:25 pst
Date: Tuesday, December 3, 1985 17:07:20
From: snyder@hplabsd
Subject: keywords
To: common-lisp@su-ai
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Is it legal to use a keyword as the name of a function?
Does a keyword have a property list?
I have always assumed the answer to these questions is "no", but I cannot find
any clear statement to this effect in the manual. The only related statement
I could find is on page 175, and is somewhat vague:
"... name conflicts are not an issue because these
symbols are used only as labels and never to carry package-specific
values or properties."
Opinions?
Alan Snyder
-------
∂03-Dec-85 1954 FAHLMAN@C.CS.CMU.EDU keywords
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Dec 85 19:54:14 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Dec 85 22:53:58-EST
Date: Tue, 3 Dec 1985 22:53 EST
Message-ID: <FAHLMAN.12164310601.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: snyder@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: keywords
In-reply-to: Msg of 3 Dec 1985 17:07-EST from snyder at hplabsd
It is certainly terrible style to use a keyword as the name of a
function or to give it any properties. The book doesn't seem to say
whether "it is an error" to do either of these things. I think it
should be an error. On the other hand, I don't know of any Common Lisp
that goes to the trouble of signaling such an error or that special
cases keyword symbols in such a way as to eliminate the function and
property-list cells.
-- Scott
∂03-Dec-85 2030 RPG More on Issues
To: quinquevirate@SU-AI.ARPA
Scott has raised what I consider the most important issues. From what
I understand, if the `club' is a corporation (of a certain type?), then
the corporation can be sued, but not the individuals. This way
Xerox can destroy the club, but not us.
Would Xerox (for example) want to destroy us? I doubt it. Suppose
we form no organizationat all; suppose Lucid stays friends
with Symbolics. Then Lucid and Symbolics can decide to proceed with
Common Lisp as we and they see fit. With even this coalition, people have
to follow or be out of the game. If we add DEC to the coalition, all
doubt about the efficacy of this plan disappear.
The point is that Common Lisp is almost as much of a defacto standard
as could be expected under any situation - witness: Xerox and Fateman
(Franz) have caved in. Given that, if some corporation or private individual
brought a suit, it would simply smear the corporation's image.
The situation was different before everyone recognized Common Lisp as
*the* Lisp. Before that, we could have been sued for trying to establish
a standard. Now anyone who tried to `break' the standard would be
in a bad situation.
So, maybe the right thing to do is nothing, except to pretend that there
is a Common Lisp Group that is making decisions somewhere.
-rpg-
∂04-Dec-85 0120 TIM@MIT-MC.ARPA The variables +, -, *, and /
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 01:19:57 PST
Date: Wed, 4 Dec 85 04:22:30 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: The variables +, -, *, and /
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].740954.851204.TIM>
It seems unfortunate that the variables +, -, *, and / were reserved for use
by the Top-Level Loop. This choice of names makes it difficult to build the
run-time environment for Scheme-like language that compiles into Common Lisp
and that supports the illusion that there are no separate function and value
cells. If these variables had not been reserved, one could
(DEFCONSTANT + #'+)
(DEFCONSTANT * #'*)
etc...
so that
((IF SUM? + *) X Y)
could be simply compiled into
(FUNCALL (IF SUM? + *) X Y)
Sigh...
∂04-Dec-85 0301 wagner%fang@gswd-vms minor index errors
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 03:01:13 PST
Received: from fang.GSD (fang.ARPA) by gswd-vms.ARPA (5.9/5.6)
id AA00873; Wed, 4 Dec 85 09:15:19 CST
Message-Id: <8512041515.AA00873@gswd-vms.ARPA>
Date: Wed, 4 Dec 85 09:04:51 cst
From: wagner%fang@gswd-vms (Fran Wagner)
To: common-lisp@su-ai.arpa
Subject: minor index errors
Cc: wagner%fang@gswd-vms
These may be known, but in CLtL index:
Entry for MULTIPLE-VALUES-LIMIT is 1325, should be 135.
Main entry for THE is 162-163, should be 161-162.
∂04-Dec-85 0310 smh@mit-ems.ARPA Re: The variables +, -, *, and /
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 03:09:24 PST
Received: by mit-ems.ARPA (4.12/4.8) id AA11143; Wed, 4 Dec 85 07:43:55 est
Date: Wed, 4 Dec 85 07:43:55 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8512041243.AA11143@mit-ems.ARPA>
To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
Subject: Re: The variables +, -, *, and /
> From: Tim McNerney <TIM@MIT-MC.ARPA>
> Subject: The variables +, -, *, and /
>
> It seems unfortunate that the variables +, -, *, and / were reserved
> for use by the Top-Level Loop. This choice of names makes it difficult
> to build the run-time environment for Scheme-like language that
> compiles into Common Lisp and that supports the illusion that there are
> no separate function and value cells. If these variables had not been
> reserved, one could
>
> (DEFCONSTANT + #'+)
> (DEFCONSTANT * #'*)
> etc...
>
> so that
>
> ((IF SUM? + *) X Y)
>
> could be simply compiled into
>
> (FUNCALL (IF SUM? + *) X Y)
Perhaps these symbols aren't the real problem: CL compilers tend to
have built-in knowledge about certain special forms that a user can't
easily modify. So if you're really scheming up a language with
different semantics for the functional position of a form, you'll
probably have to write new top-level loops for both compiler and
interpreter which preprocess all top-level forms appropriately. Your
top-level interpreter loop would probably have a reentrant top-level
unwind-protect so the user doesn't ever fall out into the CL one, even
during error recovery. Thus, the CLtL top-level loop won't be around
to mess with +, ++, etc.
∂04-Dec-85 0312 BSG@SCRC-STONY-BROOK.ARPA keywords
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 03:12:23 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 366846; Wed 4-Dec-85 09:14:05-EST
Date: Wed, 4 Dec 85 09:25 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: keywords
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12164310601.BABYL@C.CS.CMU.EDU>
Message-ID: <851204092534.6.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Tue, 3 Dec 1985 22:53 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
It is certainly terrible style to use a keyword as the name of a
function or to give it any properties. The book doesn't seem to say
whether "it is an error" to do either of these things. I think it
should be an error. On the other hand, I don't know of any Common Lisp
that goes to the trouble of signaling such an error or that special
cases keyword symbols in such a way as to eliminate the function and
property-list cells.
-- Scott
Symbolics Common Lisp relies heavily on the property lists of keywords.
Given that a keyword is "an indicator that means X in context Y",
it is right reasonable that context Y might want to hang properties off
of it to implement that.
∂04-Dec-85 0806 FAHLMAN@C.CS.CMU.EDU keywords
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Dec 85 08:03:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Dec 85 10:57:03-EST
Date: Wed, 4 Dec 1985 10:56 EST
Message-ID: <FAHLMAN.12164442247.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: keywords
In-reply-to: Msg of 4 Dec 1985 09:25-EST from Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>
Symbolics Common Lisp relies heavily on the property lists of keywords.
Given that a keyword is "an indicator that means X in context Y",
it is right reasonable that context Y might want to hang properties off
of it to implement that.
OK, I guess I accept that this is not so terrible a thing to do. If the
property names are package-specific, it shouldn't bother them that they
are sharing the same package-neutral keyword, since the different uses
still have a way of staying out of each other's way. It strikes me as a
bit unclean, but maybe that's just that I like the abstraction of a
keyword as a pure token.
I would still be inclinded to holler at anyone naming a function :FOO,
however.
-- Scott
∂04-Dec-85 0814 FAHLMAN@C.CS.CMU.EDU The variables +, -, *, and /
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Dec 85 08:13:58 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Dec 85 11:13:37-EST
Date: Wed, 4 Dec 1985 11:13 EST
Message-ID: <FAHLMAN.12164445251.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Tim McNerney <TIM@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: The variables +, -, *, and /
In-reply-to: Msg of 4 Dec 1985 04:22-EST from Tim McNerney <TIM at MIT-MC.ARPA>
We thought brielfly about such issues and decided that we would quickly go mad
if we tried to avoid stepping on symbols (or ways of using them) for
every other Lisp-like language. That's why there are packages. The
Common Lisp top-level will not mess around with the value of SCHEME:*,
etc. Customize the scheme symbols any way you want, and import from
the LISP package those things that happen to be right.
-- Scott
∂04-Dec-85 0833 FAHLMAN@C.CS.CMU.EDU More on Issues
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Dec 85 08:32:57 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Dec 85 11:32:13-EST
Date: Wed, 4 Dec 1985 11:32 EST
Message-ID: <FAHLMAN.12164448639.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: quinquevirate@SU-AI.ARPA
Subject: More on Issues
In-reply-to: Msg of 3 Dec 1985 23:30-EST from Dick Gabriel <RPG at SU-AI.ARPA>
First, let me say that I don't think that Xerox is the most likely
source of legal problems any more. I mentioned their name only because
they were the ones who brought the whole issue up with their
pre-Monterey threats. When the legal shit hits the fan, it will
probably come from some completely unforseen quarter.
I would be very pleased if Dick's view of incorporation protecting us
all were the case. Maybe it is -- without having a long (expensive)
talk with a lawyer, I don't know. My suspicion is that the individuals
could also be sued, as individuals. It would be hard for the assailant
to win that suit, but there is just enough precedent that it wouldn't be
considered totally groundless. And that means that there would be large
legal fees incurred by the individuals, and a strong incentive to
settle. Big corporations solve this by creating policies that if
individuals get sued as a result of their activity on behalf of the
corporation, the corporation defends the case and pays any judgement.
There also are various kinds of liability insurance covering corproate
officers. But for any of this to be credible protection, the
corporation has to have enough resources to be an effective shield.
Maybe our "home" corporations (Lucid, Symbolics, CMU,...) would cover
each of us, but that's not the usual pattern if you go off and do
something on the side, so we'd better get firm assurances to that
effect. As I said, CMU's policy on this is vague and does not inspire
me to stick my neck out.
Maybe I'm wrong about about all this. We've got to find out.
I think that the "club" model, in which there is a formal decision
mechanism (wherever it came from) to which various groups can pledge
their allegiance, is very different from the sort of informal situation
Dick describes (which is what we have now). With nobody really knowing
what the rules are, we either do not make any progress on controversial
things or we open things up for raw power politics -- whoever decides to
be the nastiest wins the decision. I have found the last year to be
extremely uncomfortable, so I am not enthusiastic about the "do nothing"
suggestion, though I guess that is another alternative that we might
want to discuss.
-- Scott
∂04-Dec-85 0837 @MIT-MC.ARPA:Soley@MIT-MC.ARPA The variables +, -, *, and /
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 08:37:45 PST
Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 DEC 85 11:37:15 EST
Date: Wed, 4 Dec 85 11:34 EST
From: Soley@MIT-MC.ARPA
Subject: The variables +, -, *, and /
To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].740954.851204.TIM>
Message-ID: <851204113446.4.SOLEY@MIT-CHERRY.ARPA>
Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 04:32:20 EST
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 01:19:57 PST
Date: Wed, 4 Dec 85 04:22:30 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: The variables +, -, *, and /
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].740954.851204.TIM>
It seems unfortunate that the variables +, -, *, and / were reserved for use
by the Top-Level Loop. This choice of names makes it difficult to build the
run-time environment for Scheme-like language that compiles into Common Lisp
and that supports the illusion that there are no separate function and value
cells. If these variables had not been reserved, one could
(DEFCONSTANT + #'+)
(DEFCONSTANT * #'*)
etc...
so that
((IF SUM? + *) X Y)
could be simply compiled into
(FUNCALL (IF SUM? + *) X Y)
Why not create a package SCHEME that doesn't import any symbols or use
any other package, and do what you like in that package, i.e.,
(LISP:DEFCONSTANT + #'LISP:+)
and build your own world? This is not unlike the Symbolics solution to
Common Lisp vs. Zetalisp on the 3600 -- two different worlds rooted at
different packages ("GLOBAL" and "SYMBOLICS-COMMON-LISP").
-- Richard
∂04-Dec-85 0844 AS@HP-HULK Re: keywords
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 08:43:13 PST
Received: from HP-HULK by hplabsd ; Wed, 4 Dec 85 08:41:11 pst
Date: Wed 4 Dec 85 08:42:23-PST
From: Alan Snyder <AS@HP-HULK>
Subject: Re: keywords
To: BSG%scrc-stony-brook.arpa@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Bernard S. Greenberg" <BSG%scrc-stony-brook.arpa@CSNET-RELAY>" of Wed 4 Dec 85 07:56:31-PST
Symbolics Common Lisp relies heavily on the property lists of keywords.
Given that a keyword is "an indicator that means X in context Y",
it is right reasonable that context Y might want to hang properties off
of it to implement that.
An alternative is to use the keyword as the indicator on a property
list attached to Y, which avoids the potential conflicts in using
a global database (a propertly list attached to a keyword).
It is inevitable that keywords will be interpreted differently
in different contexts. What you want to avoid is conflicts
that would prevent the different contexts from coexisting.
P.S.
Can a keyword be used as the name of a type?
Can a keyword be used as the name of a block?
Can a keyword be used as a tag?
-------
∂04-Dec-85 1006 KMP@SCRC-STONY-BROOK.ARPA The variables +, -, *, and /
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 10:05:26 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367089; Wed 4-Dec-85 13:02:25-EST
Date: Wed, 4 Dec 85 13:05 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: The variables +, -, *, and /
To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].740954.851204.TIM>
Message-ID: <851204130539.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 4 Dec 85 04:22:30 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
It seems unfortunate that the variables +, -, *, and / were reserved for use
by the Top-Level Loop. This choice of names makes it difficult to build the
run-time environment for Scheme-like language that compiles into Common Lisp
and that supports the illusion that there are no separate function and value
cells. If these variables had not been reserved, one could
(DEFCONSTANT + #'+)
(DEFCONSTANT * #'*)
etc...
so that
((IF SUM? + *) X Y)
could be simply compiled into
(FUNCALL (IF SUM? + *) X Y)
Sigh...
The good Scheme dialects all do modules via closure hacks, rather than via
read-time hacks like packages. As such, there's no reason you can't build a
Scheme package which shadows those symbols and which all Scheme users share.
Talk to Jonathan Rees -- I think he's done just that with a Scheme hack he
wrote to run in CL.
∂04-Dec-85 1019 BSG@SCRC-STONY-BROOK.ARPA Re: keywords
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 10:19:27 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367107; Wed 4-Dec-85 13:16:30-EST
Date: Wed, 4 Dec 85 13:28 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: keywords
To: AS%HP-HULK@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 4 Dec 85 11:42-EST from Alan Snyder <AS@HP-HULK>
Message-ID: <851204132801.3.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed 4 Dec 85 08:42:23-PST
From: Alan Snyder <AS@HP-HULK>
Symbolics Common Lisp relies heavily on the property lists of keywords.
Given that a keyword is "an indicator that means X in context Y",
it is right reasonable that context Y might want to hang properties off
of it to implement that.
An alternative is to use the keyword as the indicator on a property
list attached to Y, which avoids the potential conflicts in using
a global database (a propertly list attached to a keyword).
When propertly implemented [sorry], you use packages to isolate these
things. The issue is no different than with any other symbol.
It is inevitable that keywords will be interpreted differently
in different contexts. What you want to avoid is conflicts
that would prevent the different contexts from coexisting.
That's why you use property lists.
∂04-Dec-85 1109 BSG@SCRC-STONY-BROOK.ARPA Re: keywords
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 10:19:27 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367107; Wed 4-Dec-85 13:16:30-EST
Date: Wed, 4 Dec 85 13:28 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: keywords
To: AS%HP-HULK@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 4 Dec 85 11:42-EST from Alan Snyder <AS@HP-HULK>
Message-ID: <851204132801.3.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed 4 Dec 85 08:42:23-PST
From: Alan Snyder <AS@HP-HULK>
Symbolics Common Lisp relies heavily on the property lists of keywords.
Given that a keyword is "an indicator that means X in context Y",
it is right reasonable that context Y might want to hang properties off
of it to implement that.
An alternative is to use the keyword as the indicator on a property
list attached to Y, which avoids the potential conflicts in using
a global database (a propertly list attached to a keyword).
When propertly implemented [sorry], you use packages to isolate these
things. The issue is no different than with any other symbol.
It is inevitable that keywords will be interpreted differently
in different contexts. What you want to avoid is conflicts
that would prevent the different contexts from coexisting.
That's why you use property lists.
∂04-Dec-85 1344 MLY@MIT-MC.ARPA keywords
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 13:44:21 PST
Date: Wed, 4 Dec 85 16:46:53 EST
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject: keywords
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].741648.851204.MLY>
That's why you use hashtables
∂05-Dec-85 0023 REM%IMSSS.#Pup@SU-SCORE.ARPA Bad to hang properties off keywords to install their semantics
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 00:23:09 PST
Received: from IMSSS by Score with Pup; Thu 5 Dec 85 00:20:13-PST
Date: 5 Dec 1985 0020-PST
From: Rem@IMSSS
Subject: Bad to hang properties off keywords to install their semantics
To: COMMON-LISP%SU-AI@SCORE
cc: BSG%SCRC-STONY-BROOK.ARPA@SCORE
I don't think it's a good idea to implement keyword usage (semantics) by
having each function that uses that keyword to hang a property off that
keyword. The reason is you can have hundreds of different uses for a single
keyword (for example :REVERSE to do some operation backwards from default,
:IP to do something in place, :FAST to make it run fast, etc.), so then
it takes a long time each time you use that keyword for the function to
scan down the keyword's property list looking for the one item that
tells this particular function what to do while ignoring all the other
properties that are used by other functions. Better to hang the keyword
as a property-tag off the property list of the function, that way the
search is for the various keywords used by one function rather than the
various functions that use one keyword and thus the search length is
under the control of whoever wrote that function rather than being the
total search length by however many packages may be loaded.
As an alternative to using the property list of either the keyword
or the funcion, you could use the value cell of that keyword or function
pointing to a hash table, although in the case of keywod.value-->hashtable
you have to a general concensus.
One other problem with hanging anything at all of a shared thing such as
a keyword property-list cell, is that if you have interrupts you have
to carefully interlock all updates. If you hang things off the function
name instead, you only have to interlock against other processes in
the same package, which may be a lot more managable.
In my opinion, it's totally painful to have either value or function
cells hanging off a keyword, except in the case where there is some
global agreement about that that cell will hold (such as a hashtable),
and it's workable but rather inefficient to put properties on the keyword.
-------
∂05-Dec-85 0118 @SU-SCORE.ARPA:DOUG@SU-CSLI.ARPA Bad to hang properties off keywords to install their semantics
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 01:18:01 PST
Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 01:15:03-PST
Date: 5 Dec 1985 01:17 PST (Thu)
Message-ID: <DOUG.12164631704.BABYL@SU-CSLI.ARPA>
From: Doug Cutting <DOUG@SU-CSLI.ARPA>
To: Rem@IMSSS
Cc: BSG%SCRC-STONY-BROOK.ARPA@SCORE, COMMON-LISP%SU-AI@SCORE,
Doug@SU-CSLI.ARPA
Subject: Bad to hang properties off keywords to install their semantics
In-reply-to: Msg of 5 Dec 1985 00:20-PST from Rem at IMSSS
Date: Thursday, 5 December 1985 00:20-PST
From: Rem at IMSSS
[...] it takes a long time each time you use that
keyword for the function to scan down the keyword's property list
looking for the one item that tells this particular function what to
do while ignoring all the other properties that are used by other
functions. [...]
This seems like an implementation issue and has little to do with
what the language standard should be.
∂05-Dec-85 0135 REM@IMSSS Implementation issue? (re proplist on keyword)
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1985-Dec-05 01:33:56 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1985 December 05 01:33:25 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132504103204.G0353
From: Robert Elton Maas <REM@IMSSS.STANFORD.EDU>
To:DOUG@SU-CSLI.ARPA
CC:COMMON-LISP@SAIL.STANFORD.EDU
subject:Implementation issue? (re proplist on keyword)
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
| Date: 5 Dec 1985 01:17 PST (Thu)
| From: Doug Cutting <DOUG@SU-CSLI.ARPA>
| Subject: Bad to hang properties off keywords to install their semantics
| Date: Thursday, 5 December 1985 00:20-PST
| From: Rem at IMSSS
| [...] it takes a long time each time you use that
| keyword for the function to scan down the keyword's property list
| looking for the one item that tells this particular function what to
| do while ignoring all the other properties that are used by other
| functions. [...]
| This seems like an implementation issue and has little to do with
| what the language standard should be.
Common LISP has already gotten into the implementation mess here by
insisting adamently that a property list MUST be an alternating list
rather than an ASSOC list or a hashtable etc. Since we've forced the
implementor to make it a linear list of a given format, we ought not
to then encourage LUSER programmers to mis-use it by hanging one
property per function off this one poor daisy-chain
(linear-liked-list) so that the ensemble of such additions in a large
system makes simple functions run very slow searching down that list.
∂05-Dec-85 0638 @SU-SCORE.ARPA:BSG@SCRC-YUKON.ARPA Bad to hang properties off keywords to install their semantics
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 06:38:27 PST
Received: from SCRC-YUKON.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 06:13:54-PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 176322; Thu 5-Dec-85 09:14:32-EST
Date: Thu, 5 Dec 85 09:19 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Bad to hang properties off keywords to install their semantics
To: Rem@IMSSS, COMMON-LISP%SU-AI@SU-SCORE.ARPA
In-Reply-To: The message of 5 Dec 85 03:20-EST from Rem@IMSSS
Message-ID: <851205091935.9.BSG@CONCORD.SCRC.Symbolics.COM>
Date: 5 Dec 1985 0020-PST
From: Rem@IMSSS
I don't think it's a good idea to implement keyword usage (semantics) by
having each function that uses that keyword to hang a property off that
keyword. The reason is you can have hundreds of different uses for a single
keyword.
I don't see how that's different than the case with any symbol, except that
there is greater likelihood that there will be more code that knows about it.
What about "t"? Or "print"? Is it a good idea to put properties on them?
One of the profound features of Lisp is the set of services done
magically by the reader, most specifically, interning, done before the
program is even run. That you do not have to look up names in symbol
tables, in the course of your program, as in other languages, but can go
"directly" to a referenced symbol and inspect its properties: this is a
major linguistic feature. You pay for this somewhere; Property lists
assume you have many more symbols than things you might want to say
about any of them. When that is not so, you pay. That is the tradeoff
of using property lists at all. Saying "hey, for keywords, there is
some chance you'll really have to start paying", is OK, but putting the
blame for the problem anywhere but with the basic idea of property lists
(or, as has been noted, the requirement of cons-pair implementation) is
false.
∂05-Dec-85 0841 AS@HP-HULK Keywords with cells
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 08:40:38 PST
Received: from HP-HULK by hplabsd ; Thu, 5 Dec 85 08:38:45 pst
Return-Path: <REM%IMSSS.#Pup@SU-SCORE.ARPA>
Received: from hplabsd by HP-HULK with TCP; Wed 4 Dec 85 23:58:18-PST
Received: from SU-SCORE.ARPA by hplabsd ; Wed, 4 Dec 85 23:56:39 pst
Received: from IMSSS by Score with Pup; Wed 4 Dec 85 23:55:12-PST
Date: 4 Dec 1985 2356-PST
From: Rem@IMSSS
Subject: Keywords with cells
To: snyder%HPLABS.ARPA@SCORE
Resent-Date: Thu 5 Dec 85 08:40:05-PST
Resent-From: Alan Snyder <AS@HP-HULK>
Resent-To: common-lisp@SU-AI.ARPA
I thought one of the reasons for having keywords in their own package
was that you can make that a stripped down package that is just a bare
hashtable with no value/function/property cells? I agree "is an error"
should be the case, so if such is the case you truly do get a crashout,
and in implementations that have full package with cells it's up to
the implementor to decide whether to check the "error" or not.
-------
∂05-Dec-85 1049 LOOSEMORE@UTAH-20.ARPA keywords
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 10:49:30 PST
Date: Thu 5 Dec 85 11:48:31-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: keywords
To: common-lisp@SU-AI.ARPA
Message-ID: <12164735616.32.LOOSEMORE@UTAH-20.ARPA>
Personally, I think that implementing keywords without value/function/property
cells is a rotten idea. Essentially, this would make keywords be symbols
that aren't really symbols after all. Making the behavior of symbols which
just happen to be interned in the keyword package inconsistent with everything
else has the potential for causing real problems for the unsuspecting user.
If SYMBOLP is true of an object, then all of the functions defined on symbols
should work on that object.
-Sandra
-------
∂05-Dec-85 1101 FAHLMAN@C.CS.CMU.EDU Keywords with cells
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Dec 85 11:01:28 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 5 Dec 85 14:01:04-EST
Date: Thu, 5 Dec 1985 14:00 EST
Message-ID: <FAHLMAN.12164737885.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: Keywords with cells
I thought one of the reasons for having keywords in their own package
was that you can make that a stripped down package that is just a bare
hashtable with no value/function/property cells?
I don't think that this was aprt of the motivation for having a separate
keyword package. The main reason was just so that every package could
get at keywords with equal facility, and so that a keyword with the same
spelling would be EQ in every context. This was thought to be desirable
since keywords are used primarily as tokens and not as places to stash
package-dependent data.
-- Scott
∂05-Dec-85 1649 DLW@SCRC-STONY-BROOK.ARPA Charter stuff
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 16:49:00 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 368382; Thu 5-Dec-85 18:18:24-EST
Date: Thu, 5 Dec 85 18:25 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Charter stuff
To: Fahlman@C.CS.CMU.EDU, quinquevirate@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12164056344.BABYL@C.CS.CMU.EDU>
Message-ID: <851205182509.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Issue 1: I agree that we should go with the minimalist organization. In
addition to the reasons you presented, I add the following: (1) it's
much easier to get a smaller thing off the ground; (2) we can always
gradually grow it later, if things work out well.
Issue 2: Who decides? This is very hard. On point A, I do think it's
still an issue. Just read the mail. As I've groused before, everyone
wants to be the designer of Common Lisp. On point C, I agree that it's
not feasible. What I am most concerned about is not so much the
individual decisions (they're important too) as the general policies
that will guide the individual decisions.
Issue 3: I like your idea for having the five of us bootstrap an
organization and le it become the de facto organization. The more I
think about large meetings of diverse individuals, the more I think that
this is the way most likely to produce effective results. There's just
one thing: the meeting is coming up very soon now. Can we really put
something together before the meeting? If not, then what will happen
during all those hours allocated to discuss the charter? (Actually,
even if we do put something together, then what happens at the meeting?)
Lawyers: I think we have no choice but to consult a lawyer about this.
We will therefore need an initial dollop of cash. After an initial
consultation, we'll know more and we can decide what to do next. Since
we're all in different places, I'm not sure exactly how to arrange this
physically, unless you want to try to do it sometime next week. I'm
pretty sure I can get good recommendations for lawyers in the area,
though whether I could get in to see one on such short notice I don't
know.
∂05-Dec-85 1728 FAHLMAN@C.CS.CMU.EDU ISO
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Dec 85 17:27:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 5 Dec 85 20:24:17-EST
Date: Thu, 5 Dec 1985 20:24 EST
Message-ID: <FAHLMAN.12164807653.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: quinquevirate@SU-AI.ARPA
Subject: ISO
First, a minor item: I got a copy of CMU's professional liability policy
today, and it appears that they eliminated most of the vagueness last
summer. So if I am doing something for the good of the community as a
representative of CMU, and if I am not being paid for it (except for
reasonable expenses), and if I believe that I am operating within the
law, and if I get sued, CMU is supposed to pay legal expenses and any
judgement or settlement. The CMU trustees could decide to abrogate this
policy, but that's a very small risk that I am willing to assume. So I
feel a lot better about my own legal risks if I should take part in some
organization. I hope that all of you are similarly covered by your
respective employers.
More important: I had a long talk with Bob Mathis today. He's the guy
who has coordinated the process of turning Ada into an ISO standard, and
who has taken the first steps toward doing the same thing for Common
Lisp. He seems to have a very good grasp of the whole process. He's
also very persuasive.
Mathis says that he is confident that we could form a standards
committee within ISO that could get Common Lisp ratified pretty much as
is, and that would fairly represent the community as it now exists in
considering future changes. For example, we could get all the right
people appointed to the technical committee that makes the decisions,
and this technical committee would be able to do their work via the
arpanet, just as we do it now. I was quite skeptical about all this,
but Mathis has been there and seems to ahve all the right connections
within ANSI and ISO. If we want him to, he is willing to play a role in
this as the "convener" or the committee, and (with some help from Steve
Squires) to handle the political process of getting this thing set up
within ISO.
Well, as I said earlier, the best possible case is if we can actually
get ISO to bless Common Lisp as we would like it to be defined. I
didn't think this was possible, but after talking with Mathis, I think
it may be possible after all. In fact, if we go this way, we may not
need any other formal organization -- the ISO technical committee would
be able to speak with authority on what Common Lisp is, or at least on
what they are going to recommend for adoption by ISO when the time
comes. Of course, we'll still need all those services, but if DARPA
goes ahead with the plans to set up ISI to do this job, maybe we can
do that without a separate organization as well.
It's very attractive to believe that we could do this in the "right" way
and avoid having to create yet another bureaucratic organization in the
world. I'm not sure that I believe this yet, but I think that it would
be worthwhile to introduce the ISO possibility early in the Boston
meeting and to explore this option throughly before we spend too much
time talking about a separate organization for Common Lisp. This may be
worth a shot.
Of course, if people come through with enough of those horror stories
that Dick asked for, then this whole idea is a non-starter.
-- Scott
∂06-Dec-85 0028 TIM@MIT-MC.ARPA The variables +, -, *, and /
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 00:28:09 PST
Date: Fri, 6 Dec 85 03:30:43 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: The variables +, -, *, and /
To: FAHLMAN@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, greek%bach.decnet@HUDSON.DEC.COM,
smh@MIT-EMS.ARPA
In-reply-to: Msg of Wed 4 Dec 1985 11:13 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MIT-MC.ARPA].743936.851206.TIM>
I realize that there are ways of working around the problems caused by this
unfortunate choice of names, but this is not the point. I am appealing, not
for seasoned Lisp hacker, but for the Lisp user experimenting with new
languages who is not familiar with, for instance, the subtleties of creating
packages which do not :use the LISP package.
The Common Lisp language is riddled with historical relics which were
preserved in the interest of making old programs like Macsyma have some hope
of being ported to Common Lisp (an example of this is the separate function
and value cell), but there is no reason to make the Top-Level Loop compatible
with Maclisp and their descendants. Furthermore, to reserve variable names
which admittedly do not follow the *...* convention, which are side-effected
by the Top-Level Loop, which are globally declared special, and which naive
Lisp users are likely to try use in their programs, seems inexcusable.
If Common Lisp were not supposed to be an excellent language for developing
new languages, I would not be nearly so disappointed.
Tim McNerney
ICAD, Inc.
P.S. Incidentally, please, please, let us not stumble into another discussion
about the pros and cons of separate function and value cells.
Date: Wed, 4 Dec 1985 11:13 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
We thought brielfly about such issues and decided that we would quickly go
mad if we tried to avoid stepping on symbols (or ways of using them) for
every other Lisp-like language. That's why there are packages. The
Common Lisp top-level will not mess around with the value of SCHEME:*,
etc. Customize the scheme symbols any way you want, and import from
the LISP package those things that happen to be right.
-- Scott
∂06-Dec-85 0606 GJC@MIT-MC.ARPA macsyma and common-lisp
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 06:06:22 PST
Date: Fri, 6 Dec 85 09:08:54 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: macsyma and common-lisp
To: TIM@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, FAHLMAN@C.CS.CMU.EDU
In-reply-to: Msg of Fri 6 Dec 85 03:30:43 EST from Tim McNerney <TIM at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].744105.851206.GJC>
I've heard that one too many times. Certainly it was even mentioned by
people at some of the early CL meetings that "we cant do X because of
programs like Macsyma," but that has certainly proved not the case.
When it comes to a program the size of DOE-Macsyma at least yours truly
takes the minimum work route, SHADOW EVERYTHING IN SIGHT! Keep my own
private copies of the maclisp-compatible functions because you know
you cant trust the quality (speed or accuracy) of things supposedly
done for maclisp compatibility in some of the more popular
lisp/operating-system environments. And then parts of DOE-macsyma depend
heavily on the dynamic scoping in the maclisp interpreter, and I tell
you that was a pain.
In fact, I remember a very specific statement about (SYMBOLP ()) = T,
in the early CL meetings: "we cant change that because of programs
like Macsyma" Unfortunately the facts didnt seem to matter when I
replied that Macsyma had already been brought up in NIL (which at the
time had a more rational/orthogonal type scheme) and that the fact
that (SYMBOLP ()) was now FALSE and (GET () 'ANYTHING) was now an
error had uncovered some bugs that had escaped tracking down for
years. The proof of actual experience of porting a large system to
what at the time was the post-maclisp dialect pointing to common-lisp
did not in fact matter. (Or as Hitler once said, "How many [army] divisions
does the Pope have?").
So lets not entertain any further mention of things for the benefit of
Macsyma.
∂06-Dec-85 0642 KMP@SCRC-VALLECITO.ARPA The variables +, -, *, and /
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 06:42:36 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 68648; Fri 6-Dec-85 09:42:02-EST
Date: Fri, 6 Dec 85 09:42 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: The variables +, -, *, and /
To: TIM@MIT-MC.ARPA, FAHLMAN@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, greek%bach.decnet@HUDSON.DEC.COM,
smh@MIT-EMS.ARPA
In-Reply-To: <[MIT-MC.ARPA].743936.851206.TIM>
Message-ID: <851206094203.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 6 Dec 85 03:30:43 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
I realize that there are ways of working around the problems caused by this
unfortunate choice of names, but this is not the point. I am appealing, not
for seasoned Lisp hacker, but for the Lisp user experimenting with new
languages who is not familiar with, for instance, the subtleties of creating
packages which do not :use the LISP package.
Naive users should be taught how to program using reasonable techniques.
There are recently dozens of examples of people who did langauges embedded in
another which were implemented as puns on primitive language semantics and then
had their respective jokes spoiled by changes to the language. The case that
comes immediately to mind are languages that claimed to be dynamically scopped
but which were in fact depended on their underlying language to be dynamic, so
when the underlying language became lexical, the embedded language became broken.
There are right and wrong ways to do embedded languages. People should not continue
to use broken techniques when workable ones exist.
The Common Lisp language is riddled with historical relics which were
preserved in the interest of making old programs like Macsyma have some hope
of being ported to Common Lisp (an example of this is the separate function
and value cell), but there is no reason to make the Top-Level Loop compatible
with Maclisp and their descendants. Furthermore, to reserve variable names
which admittedly do not follow the *...* convention, which are side-effected
by the Top-Level Loop, which are globally declared special, and which naive
Lisp users are likely to try use in their programs, seems inexcusable.
System constants (eg, PI, MOST-POSITIVE-FIXNUM, ARRAY-RANK-LIMIT) are already in
that namespace even if they are treated slightly differently. Your naive users had
better know about these or they'll confuse themselves. Once they've learned about
these, a few more un-starred names is not unreasonable.
Besides, Lisp is a symbol-processing language. By that we mean that it's the token
itself, not the character string which is its print-name, which is of interest.
Allowing stars on the end of the symbol's printname to dictate the semantics of a
variable is what would be inexcusable.
If Common Lisp were not supposed to be an excellent language for developing
new languages, I would not be nearly so disappointed.
The proposed solution (using packages) mentioned by all the respondents thus far
does not inhibit you from doing reasonable things. I don't know why you should be
disappointed. If you dislike packages as much as I, you should be pleased that they
offer a way for you to isolate yourself from the rest of the CL world and build
your own personalized world out of symbols whose semantics, plist, value, etc will
be untarnished by CL's hairy mechanisms. It would be far less easy to hide a CL
embedded in any of the Scheme's I know of.
Tim McNerney
ICAD, Inc.
P.S. Incidentally, please, please, let us not stumble into another discussion
about the pros and cons of separate function and value cells.
Date: Wed, 4 Dec 1985 11:13 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
We thought brielfly about such issues ...
On the subject of amateur archiving, let me say that I find including another's message
at the end of a long message like this to be silly. It gives me the impression that my
Babyl file has been trashed and that somehow the boundary between two messages has
disappeared. If I've gotten as far as reading to the point where this sort of included
message appears, I no longer need the context.
∂06-Dec-85 0702 FAHLMAN@C.CS.CMU.EDU The variables +, -, *, and /
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Dec 85 07:02:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 6 Dec 85 10:02:11-EST
Date: Fri, 6 Dec 1985 10:02 EST
Message-ID: <FAHLMAN.12164956539.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Tim McNerney <TIM@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: The variables +, -, *, and /
In-reply-to: Msg of 6 Dec 1985 03:30-EST from Tim McNerney <TIM at MIT-MC.ARPA>
In fact, we did not blindly follow precedent in this case. I remember
asking, at the time we were doing the Eval chapter, whether we should
flush these names in favor of something more mnemonic and more
standard-looking. The feeling was that these things are for use by the
user at the keyboard and that they want to be very short. Some users
have an interaction style that depends on these things very heavily.
Given that, these seemed like the one-character symbols that a user was
least likely to accidentally include in a program as a symbol, precisely
because they are so universally used as function names that they look
ugly as variables. If we had been willing to postulate an Emacs-like
top-level for every implementation, we could have come up with some
different mechanism than the use of side effects on variables to save
the recent results, but at the time we felt that we had to allow for
simple but usable top-levels. I'm not sure I'd make the same choice
today, but it's not one that look obviously crazy to me.
I think that by the time a user is playing with embedded languages, he
is not such a beginner and he had damned well better make friends with
packages. That's what they are for, and I think they are a reasonably
good solution. Note that you don't have to avoid using LISP in this
case, if *+/- is your only concern. Just create a new package, use
LISP, and shadow those specific symbols.
-- Scott
∂06-Dec-85 1223 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK ISO Standard
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 6 Dec 85 12:23:21 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a009085; 2 Dec 85 20:48 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Mon, 2 Dec 85 20:31:41 GMT
To: common-lisp@su-ai.arpa
Subject: ISO Standard
The 21 November issue of Computer Weekly (one of the UK "computer comics")
had a short article on a recent ISO meeting in Paris, entitled "Three
language standards come closer". One of the languages was C, and the
ISO would use the ANSI draft standard as a basis. The other two were
Prolog and Lisp:
At the Paris meeting ISO also set up a study group to
standardize the artificial intelligence languages, Lisp
and Prolog.
This group is to be chaired by Bob Mathis, who has been
closely involved in the development of the Ada standard.
The artificial intelligence group will report by Sept.
1986 to the ISO on the need for standards in the Lisp
and prolog languages.
They go on to say "the UK and France are already well advanced towards
a Prolog standard" but say nothing more about Lisp.
Does anyone know anything about this?
∂06-Dec-85 1321 FAHLMAN@C.CS.CMU.EDU ISO Standard
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Dec 85 13:21:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 6 Dec 85 16:05:57-EST
Date: Fri, 6 Dec 1985 16:05 EST
Message-ID: <FAHLMAN.12165022759.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK>
Cc: common-lisp@SU-AI.ARPA
Subject: ISO Standard
In-reply-to: Msg of 2 Dec 1985 15:31-EST from Jeff Dalton <jeff%aiva.edinburgh.ac.uk at cs.ucl.ac.uk>
Bob Mathis will be at the Boston meeting and will fill us all in on what
is happening with ISO, and also on what the possibilities are for
getting Common Lisp standardized under ISO in some reasonable way.
After some discussion with Mathis, I think that the idea of cooperating
in a serious way with the ISO standardization effort may be a good idea
after all. We'll see what develops in Boston.
-- Scott
∂06-Dec-85 1916 TIM@MIT-MC.ARPA The variables +, -, *, and /
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 19:16:47 PST
Date: Fri, 6 Dec 85 22:19:16 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: The variables +, -, *, and /
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Fri 6 Dec 1985 10:02 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MIT-MC.ARPA].745025.851206.TIM>
Date: Fri, 6 Dec 1985 10:02 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
I think that by the time a user is playing with embedded languages, he
is not such a beginner and he had damned well better make friends with
packages.
You would be surprised. I know people working on embedded languages who
have either never had to use packages or have only gotten screwed by them
and would prefer never to touch them again.
I suspect that you will find that the majority of graduate students in AI
using Common Lisp for their thesis project will not learn about even a
significant fraction of Common Lisp's pitfalls before they complete their
degrees. They will have neither the time nor the inclination.
Tim
∂07-Dec-85 0719 FAHLMAN@C.CS.CMU.EDU The variables +, -, *, and /
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Dec 85 07:19:11 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 7 Dec 85 10:19:00-EST
Date: Sat, 7 Dec 1985 10:18 EST
Message-ID: <FAHLMAN.12165221752.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Tim McNerney <TIM@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: The variables +, -, *, and /
In-reply-to: Msg of 6 Dec 1985 22:19-EST from Tim McNerney <TIM at MIT-MC.ARPA>
You would be surprised. I know people working on embedded languages who
have either never had to use packages or have only gotten screwed by them
and would prefer never to touch them again.
I suspect that you will find that the majority of graduate students in AI
using Common Lisp for their thesis project will not learn about even a
significant fraction of Common Lisp's pitfalls before they complete their
degrees. They will have neither the time nor the inclination.
I guess I would be surprised. Most of the grad students I've known
around CMU and MIT either go in and completely master their tools or
else they find out what they need and master that part. But maybe these
places are atypical. I grant you that some undergrads try to slide by
with the minimum competence needed to pass, but are we really designing
a language for those guys?
Anyway, if packages are really proving to be that tough for people, we
either need better training materials or else there are things in the
package system we need to fix up to make it esier to use. Probably
both. I don't think that the solution is to try to mess up the rest of
the language so that people can do embedded languages without using
packages -- we would basically have to take all the good names away from
Common Lisp in order to leave them free for other use. The +*/-
characters are just the tip of the iceberg.
-- Scott
∂07-Dec-85 1206 RPG Legal Issues
To: quinquevirate@SU-AI.ARPA
I talked to our (Lucid) lawyer yesterday about organizations that
allow, let's say, us to maintain and set standards, yet provide us
protection from personal lawsuits. The lawyer said that there are
trade-union-type organizations which set standards but are fully
protected. The danger comes when the bylaws of the organization
allows the organization to take actions or set standards that tend
to prevent companies from being competitive. So the organization
could not set advertising standards or dictate marketting policies.
Morever, the organization can be set up to be non-profit, and thereby
it would enjoy a good tax situation.
Needless to say, our lawyers know about Lucid's business, the
software business, the Common Lisp situation, and my exposure, so
I think this is a well-informed opinion.
-rpg-
∂07-Dec-85 1723 REM@IMSSS need subset of CL!
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1985-Dec-07 17:09:42 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1985 December 07 17:05:56 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132507010126.G0357
From: Robert Elton Maas <REM@IMSSS.STANFORD.EDU>
To:TIM@MIT-MC.ARPA
CC:COMMON-LISP@SU-AI.ARPA
subject:need subset of CL!
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
| Date: Fri, 6 Dec 85 22:19:16 EST
| From: Tim McNerney <TIM@MIT-MC.ARPA>
| Subject: The variables +, -, *, and /
| I suspect that you will find that the majority of graduate students in AI
| using Common Lisp for their thesis project will not learn about even a
| significant fraction of Common Lisp's pitfalls before they complete their
| degrees. They will have neither the time nor the inclination.
I take this as evidence that CL is too big. If there are so many functions
and special cases (keyword & optional args) to learn that the student
doesn't have time to learn basic stuff like packages, something is wrong.
I continue to say that we need some subset of CL that (1) can be taught
completely to a student in one semester, (2) can be implemented on a
small microcomputer by a small team of programmers in a reasonable time,
(3) can be exhaustively tested for correctness (I don't mean by exhaustive
trial of all combinations; I mean that each and every feature is tested
without exception) by a reasonable test suite.
∂07-Dec-85 2328 masinter.PA@Xerox.ARPA packages
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 7 Dec 85 23:28:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 DEC 85 23:28:42 PST
From: masinter.PA@Xerox.ARPA
Date: 7 Dec 85 23:25:37 PST
Subject: packages
To: common-lisp@su-ai.ARPA
Message-ID: <851207-232842-4561@Xerox>
I think that most people recognize that the package system is seriously
flawed, but that it was the best that was available by the time it was
necessary to publish the book. There have not as of yet been any serious
proposals for how to fix the current flaws. Perhaps this needs a
separate subcommittee.
∂08-Dec-85 0606 FAHLMAN@C.CS.CMU.EDU packages
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Dec 85 06:06:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 8 Dec 85 09:06:42-EST
Date: Sun, 8 Dec 1985 09:06 EST
Message-ID: <FAHLMAN.12165470736.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: masinter.PA@XEROX.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: packages
In-reply-to: Msg of 8 Dec 1985 02:25-EST from masinter.PA at Xerox.ARPA
I think the history of the various subcommittees shows that they don't
really begin to function until someone comes up with a concrete
proposal or at least a coherent set of objectives and ideas. Whenever
we have such a proposal, that would be the time to consider changes to
the package system, either in a subcommittee or all together.
Aside from the case-sensitivity lossage in package names, I'm not sure
what people find to be so hard. If it is just that they get confused
about what symbols live where, maybe all we need is a good tool
(Masterscope-like?) for finding out which symbols live where, which ones
shadow other sysmbols, etc., and for displaying the result in a
reasonable form.
-- Scott
∂08-Dec-85 1107 DLW@SCRC-STONY-BROOK.ARPA need subset of CL!
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Dec 85 11:07:22 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 369695; Sun 8-Dec-85 14:03:55-EST
Date: Sun, 8 Dec 85 14:10 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: need subset of CL!
To: quinquevirate@SU-AI.ARPA
In-Reply-To: SU-IMSSS.REM.A132507010126.G0357
Message-ID: <851208141046.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
I wanted to send this reply, but restrained myself.
Date: 1985 December 07 17:05:56 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS.STANFORD.EDU>
Date: Fri, 6 Dec 85 22:19:16 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: The variables +, -, *, and /
I suspect that you will find that the majority of graduate students in AI
I take this as evidence that CL is too big.
You take an off-the-cuff "I suspect" from one person as "evidence"?
Remind me not to hire you as my attorney.
∂08-Dec-85 1806 RWK@SCRC-STONY-BROOK.ARPA The variables +, -, *, and /
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Dec 85 18:06:09 PST
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 369781; Sun 8-Dec-85 21:02:38-EST
Date: Sun, 8 Dec 85 21:00 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: The variables +, -, *, and /
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Tim McNerney <TIM@MIT-MC.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12165221752.BABYL@C.CS.CMU.EDU>
Message-ID: <851208210052.9.RWK@CROW.SCRC.Symbolics.COM>
Date: Sat, 7 Dec 1985 10:18 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I guess I would be surprised. Most of the grad students I've known
around CMU and MIT either go in and completely master their tools or
else they find out what they need and master that part. But maybe these
places are atypical. I grant you that some undergrads try to slide by
with the minimum competence needed to pass, but are we really designing
a language for those guys?
Maybe the difference between grad students and us drop-outs
is that us drop-outs always read the whole manual and learn
our tools, instead of going to class?
Anyway, for the sake of students trying to do their thesis
in two weeks, I suggest we put somewhere prominent a list of
facilities of interest to people imbedding languages. Anyone
THEN not willing to read the little material involved doesn't
deserve a degree. (I read it ALL immediately, can I get a
degree?)
I'm not arguing against other proposals to make it easier to use.
But maybe we could make it a bit easier for the guy in a rush
who only wants to learn about what he needs. Probably most
people are in that situation when they start out using something
new, even if they aren't by the time they're done. We just tend
to forget the feeling once we become expert.
∂08-Dec-85 1823 MATHIS@USC-ISIF.ARPA Re: ISO Standard
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 8 Dec 85 18:23:10 PST
Date: 8 Dec 1985 18:21-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: Re: ISO Standard
From: MATHIS@USC-ISIF.ARPA
To: jeff%aiva.edinburgh.ac.uk@UCL-CS.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA] 8-Dec-85 18:21:40.MATHIS>
In-Reply-To: The message of Mon, 2 Dec 85 20:31:41 GMT from Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
At the meeting in Boston, I will be talking to people about the
ISO effort for a LISP standard. -- Bob Mathis
∂10-Dec-85 1352 hplabs!perdue@hplabsd Macrolet index bug
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 13:51:51 PST
Received: by hplabsd ; Tue, 10 Dec 85 13:49:37 pst
Date: Tuesday, December 10, 1985 11:17:28
From: perdue@hplabsd
Subject: Macrolet index bug
To: common-lisp@su-ai
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
In the manual the main index for macrolet is listed at pages 93-94.
The main reference should be to page 113 instead.
-------
∂12-Dec-85 1836 shebs%utah-orion@utah-cs.arpa Special Form Question
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 18:36:14 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA19193; Thu, 12 Dec 85 19:36:42 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA20979; Thu, 12 Dec 85 19:36:38 MST
Date: Thu, 12 Dec 85 19:36:38 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8512130236.AA20979@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Special Form Question
This may seem like an exceptionally stupid question, but what should
the following do?
(setf (symbol-function 'foo) (symbol-function 'quote))
(foo (a b c))
While CLtL prohibits defining new special forms, it's not clear
that this use is defining a "new" form. Also, symbol-function on
special forms is allowed to return something (whose exact nature is
carefully left vague) which presumably can be used elsewhere. The
whole thing sure looks like a nod to implementations which still have
nasty fexprs :-), and for which the above trick would be valid.
Am I right? Or is it OK for symbol-function of a special form to
signal an error?
stan shebs
∂13-Dec-85 0705 DLW@SCRC-STONY-BROOK.ARPA Special Form Question
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 07:04:19 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 373758; Fri 13-Dec-85 10:04:22-EST
Date: Fri, 13 Dec 85 10:12 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Special Form Question
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8512130236.AA20979@utah-orion.ARPA>
Message-ID: <851213101236.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 12 Dec 85 19:36:38 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
This may seem like an exceptionally stupid question, but what should
the following do?
(setf (symbol-function 'foo) (symbol-function 'quote))
(foo (a b c))
It certainly should not be required to make foo act like quote. But
exactly how to rule it out is not completely clear. symbol-function is
sort of useful as a tool to examine your environment, so having it
signal an error might not be appropriate. Perhaps the function that the
setf turns into should be responsible for not storing special forms? Or
maybe this is too implementation dependant, and we should just say "it
is an error" to store such a thing?
∂13-Dec-85 0708 NGALL@BBNG.ARPA Re: Special Form Question
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 07:08:23 PST
Date: 13 Dec 1985 10:04-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Special Form Question
From: NGALL@BBNG.ARPA
To: shebs%utah-orion@UTAH-CS.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]13-Dec-85 10:04:31.NGALL>
In-Reply-To: <8512130236.AA20979@utah-orion.ARPA>
Date: Thu, 12 Dec 85 19:36:38 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
To: common-lisp@su-ai.arpa
Subject: Special Form Question
Message-ID: <8512130236.AA20979@utah-orion.ARPA>
This may seem like an exceptionally stupid question, but what should
the following do?
(setf (symbol-function 'foo) (symbol-function 'quote))
(foo (a b c))
While CLtL prohibits defining new special forms, it's not clear
that this use is defining a "new" form. Also, symbol-function on
special forms is allowed to return something (whose exact nature is
carefully left vague) which presumably can be used elsewhere. The
whole thing sure looks like a nod to implementations which still have
nasty fexprs :-), and for which the above trick would be valid.
Am I right? Or is it OK for symbol-function of a special form to
signal an error?
stan shebs
--------------------
It is clearly NOT OK for (symbol-function 'quote) to signal an error, pg. 90.
It is not clear (in CLtL) whether
(setf (symbol-function 'foo)
#<object-representing-special-form-quote>)
is an error ("The set of special forms is fixed in CL." pg. 57);
must "work" (Note that there is no restriction on the "specified definition"
that may be assigned to the symbol-function gen. var., pg. 90;
is left undefined (Note that vagueness of what symbol-function of a special
form returns and what special-form-p returns (and what can be done with them).
I vote for "is an error" for the simple reason that portable code analyzers
(incl. compilers) count on the fact that they must have special-purpose
code only for the symbols in Table 5-1 (cf. the code-analysis "algorithm" on
pg. 57). If we break this restriction, portable code ananlyzers would become
much more complicated (if not impossible without further CLtL revisions).
Besides, why would anyone need to do such a thing? Remember macros?...
-- Nick
∂13-Dec-85 0744 shebs%utah-orion@utah-cs.arpa Re: Special Form Question
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 07:43:55 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA26265; Fri, 13 Dec 85 08:44:27 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA22517; Fri, 13 Dec 85 08:44:24 MST
Date: Fri, 13 Dec 85 08:44:24 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8512131544.AA22517@utah-orion.ARPA>
To: NGALL@bbng.arpa, shebs%utah-orion@utah-cs.arpa
Subject: Re: Special Form Question
Cc: common-lisp@su-ai.arpa
From NGALL@BBNG.ARPA Fri Dec 13 08:08:41 1985
(setf (symbol-function 'foo) (symbol-function 'quote))
(foo (a b c))
I vote for "is an error" for the simple reason that portable code analyzers
(incl. compilers) count on the fact that they must have special-purpose
code only for the symbols in Table 5-1 (cf. the code-analysis "algorithm" on
pg. 57). If we break this restriction, portable code ananlyzers would become
much more complicated (if not impossible without further CLtL revisions).
Besides, why would anyone need to do such a thing? Remember macros?...
There are a lot of things that CL talks about that nobody would really do!
This particular issue has a lot to do with whether an implementation needs
to support fako fexprs secretly, or whether it can treat each special form
case-by-case in both the compiler and interpreter. Without naming names,
I can point to CL implementations which *do* have fexprs, and which *do*
allow the above, but if I were to sit down and do an implementation today,
I wouldn't have anything even remotely resembling fexpr functions at all.
"Is an error" seems like the right answer.
stan shebs
∂13-Dec-85 0804 FAHLMAN@C.CS.CMU.EDU Special Form Question
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85 08:03:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Dec 85 11:03:40-EST
Date: Fri, 13 Dec 1985 11:03 EST
Message-ID: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
Cc: common-lisp@SU-AI.ARPA
Subject: Special Form Question
In-reply-to: Msg of 12 Dec 1985 21:36-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
You do come up with the most imaginative questions...
We clearly do not require that
(setf (symbol-function 'foo) (symbol-function 'quote))
somehow makes foo act like quote. Nor do we explicitly require this to
signal an error. The case that you describe is so perverse that I do
not think it is worthwhile for those implementations that use something
like internal FEXPRs in the interpreter to bother checking that they are
being called in a legitimate way.
I think the best position to take is the following: Symbols that name
special forms do have symbol-function slots, just like any other symbol.
The implementation is allowed, but not required, to put some strange
object in that slot, and we cannot prevent users from getting their
hands on this object if it exists. However, the nature of this object,
if it exists, is completely unspecified and users cannot count on doing
anything useful with it. It is an error to funcall or apply this thing,
or to stick it in a symbol-function slot of some symbol and then
evaluate a form with that symbol as the Car.
-- Scott
∂13-Dec-85 1022 Moon@SCRC-QUABBIN.ARPA Special Form Question
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 10:22:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228016; Fri 13-Dec-85 13:17:12-EST
Date: Fri, 13 Dec 85 13:17 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Special Form Question
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
Message-ID: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 13 Dec 1985 11:03 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
We clearly do not require that
(setf (symbol-function 'foo) (symbol-function 'quote))
somehow makes foo act like quote. Nor do we explicitly require this to
signal an error. The case that you describe is so perverse that I do
not think it is worthwhile for those implementations that use something
like internal FEXPRs in the interpreter to bother checking that they are
being called in a legitimate way.
I think the best position to take is the following: Symbols that name
special forms do have symbol-function slots, just like any other symbol.
The implementation is allowed, but not required, to put some strange
object in that slot, and we cannot prevent users from getting their
hands on this object if it exists. However, the nature of this object,
if it exists, is completely unspecified and users cannot count on doing
anything useful with it. It is an error to funcall or apply this thing,
or to stick it in a symbol-function slot of some symbol and then
evaluate a form with that symbol as the Car.
I agree. I'd like to propose a clarification about macros. If a symbol is
the name of a macro, then symbol-function returns an unspecified object that
it is an error to funcall or apply, however sticking that object into the
symbol-function slot of another symbol does make that other symbol name the
same macro. The alternative would be to say that it's just as illegal for
macros as for special forms.
∂13-Dec-85 1101 NGALL@BBNG.ARPA Re: Special Form Question
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 11:00:54 PST
Date: 13 Dec 1985 13:56-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Special Form Question
From: NGALL@BBNG.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]13-Dec-85 13:56:25.NGALL>
In-Reply-To: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
Date: Fri, 13 Dec 1985 11:03 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
Subject: Special Form Question
In-Reply-To: Msg of 12 Dec 1985 21:36-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
Message-ID: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
You do come up with the most imaginative questions...
We clearly do not require that
(setf (symbol-function 'foo) (symbol-function 'quote))
somehow makes foo act like quote. Nor do we explicitly require this to
signal an error. The case that you describe is so perverse that I do
not think it is worthwhile for those implementations that use something
like internal FEXPRs in the interpreter to bother checking that they are
being called in a legitimate way.
I think the best position to take is the following: Symbols that name
special forms do have symbol-function slots, just like any other symbol.
Wrong. A CL symbol does not have a function as a "user-visible
component" (i.e., slot; cf. pg. 163). Since CLtL goes out of its way
to point this out, I think it is a good idea to not slip back into
definition by implementation (are any implementtations NOT using
function cells?).
The implementation is allowed, but not required, to put some strange
object in that slot, and we cannot prevent users from getting their
hands on this object if it exists. However, the nature of this object,
if it exists, is completely unspecified and users cannot count on doing
anything useful with it. It is an error to funcall or apply this thing,
If this "strange object" is to be completely unspecified, then the
section of the defintion of special-form-p (pg. 91) that DOES specify
what this strange object "typically" is, should be made an
Implementation Note.
or to stick it in a symbol-function slot of some symbol and then
evaluate a form with that symbol as the Car.
-- Scott
--------------------
-- Nick
∂13-Dec-85 1109 NGALL@BBNG.ARPA Re: Special Form Question
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 11:09:25 PST
Date: 13 Dec 1985 14:05-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Special Form Question
From: NGALL@BBNG.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]13-Dec-85 14:05:25.NGALL>
In-Reply-To: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 13 Dec 85 13:17 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
Subject: Special Form Question
In-Reply-To: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
Message-ID: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
...
I agree. I'd like to propose a clarification about macros. If a symbol is
the name of a macro, then symbol-function returns an unspecified object that
it is an error to funcall or apply, however sticking that object into the
symbol-function slot of another symbol does make that other symbol name the
same macro. The alternative would be to say that it's just as illegal for
macros as for special forms.
--------------------
What about symbols that have both a macro definition and are
special-form names?
I prefer the alternative. Use macro-function to get the macro,
special-form-p to "typically" get the fexpr :-), and symbol-function
for honest-to-god functions. Otherwise, implementations that don't
just return the value of the function cell will be forced to put macro
and special-form accessing machinery into symbol-function.
-- Nick
∂13-Dec-85 1155 shebs%utah-orion@utah-cs.arpa Clarification Comments (long)
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 11:55:13 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA00503; Fri, 13 Dec 85 12:55:43 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA23353; Fri, 13 Dec 85 12:55:38 MST
Date: Fri, 13 Dec 85 12:55:38 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8512131955.AA23353@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Clarification Comments (long)
The following long message is a set of knee-jerk reactions to Guy's list
of suggested clarifications. They are (more or less) keyed by page, as
in the printed list handed out at the meeting. You'll need the list,
since I left out context to save space.
1 There are at least two reasons for having undo operations. The most
obvious is for user-friendliness and mistake-fixing, while the other
reason is to support really arcane things. I would put the various
"un" package functions into the first category, while something like
makunbound is more in the second. If CL is the subset used for portable
programs, then it seems to me that functions whose sole purpose is to
improve the user interface are less important; they are unlikely to
show up in programs to be ported. From that point of view, a general
undo is not appropriate for CL, although certain specific things like
delete-package might be OK. If an implementation *does* have an undo,
I would like to see it as elaborate as the facilities in Interlisp -
fixing a mistaken (setq *macroexpand-hook* #'tailp) shouldn't result
in (makunbound '*macroexpand-hook*)!
47 This is OK, although it feels a little uncomfortable to include the
name of a local keyword variable in a proclamation that may be in
another file. Bye bye alpha conversion...
51 Yes!
56, 58 Go for it.
60 Yes, on the principle that it might allow more optimization
(I have here in my hand a list of 203 known compiler optimizations that
this would make possible...).
82 Sounds like a good idea - I even thought back over old code to
see it would simplify any complicated conditionals. Sadly, I couldn't
remember any.
107 Yup, on the principle of decoupling functionality.
113 Sounds OK, but do I vaguely remember battles on possibly difficult
problems with this one?
120 Yes, on the principle of orthogonality, but it'll fatten up the
code a bit (unless of course one has the fabled "sufficiently good"
compiler).
130 I didn't realize until now that tagbody does have a restriction
on body contents. That seems wrong to me. Presumably lots of things
will macroexpand into tagbodies, and every one inherits the same
restriction. Worse, one implementation's dolist will macroexpand
into a tagbody, while in another, it will be a special form. Why
not say that integers and symbols are tags, and everything else is
a form? Or that all non-lists are tags?
130 Might have same problems as previous point, but it seems less
likely to be a problem. OK by me (but needs more thought).
144 Seems reasonable, although I'm sure there's some subtle point
I'm missing about why macro-function should be defined this way,
and symbol-function should not.
145 Yes! Although it needs a fairly careful specification.
Should parse-body work on all def* bodies?
145 Yes.
145 Yes. (Why so many clarifications for macros anyway? :-)
158 Yup.
159 Good.
162 OK.
172 Yes, although it breaks much code...
186 Doesn't seem *wrong*, but not clear why one can't explicitly test
symbol-package and intern instead. Sounds like a frob.
187 Ah yes, making the spec conform to reasonable implementations!
202 Sure.
212 Isn't a proposal that's *already* been accepted that we could
follow?
226 "All in all, it's just another frob in the spec..."
239 This one seems really unmotivated - why the bits and not the
font anyway? Perhaps we could add keywords to char comparison
to tell which parts of the char are to be considered :-)
249 I think the effect of mapping over circular lists should be
to delete the offending program and harass the user every time
he/she starts up the Lisp thereafter. Trying to make all of the
functions work on arbitrarily hairy list structure involves too
many imponderables - mapcar and "circular" lists is just the tip
of the iceberg.
268 Yes - I always assumed this one slipped through the cracks.
Should it work on circular lists? :-)
275 Yes.
283 Yes. Does anybody actually have an implementation for which these
functions would be more than structure accessors that already exist
internally?
293 Yes. The array functions are, shall we say, sketchy; these seem
like worthwhile additions. There are probably others.
295 Yes - how would anyone adjust *part* of an array?
297 Sounds OK to me, but I haven't studied the issues closely.
297 Yes, to be consistent with p. 295 clarification.
307 Yes.
307 Yes, and should this be extended to cover both plain slot names
and ones with conc-names added? Or is the normal "functions stepping
on each other" protocol sufficient?
321 Seems like a frob, but there's no real reason not to do it.
322 Makes sense.
328 Yes, but I would go further and say that there are no requirements
*at all* about which streams are bound to which, or whether any are
bound at all! But then one would have to define more behavior
(the issue has already come up of yes-or-no-p being called when one
is running a batch job, and doesn't plan to login until next week).
425 Yes.
439 Pretty dramatic clarification! This isn't even hinted at in the
book. OK by me, although made unnecessary if uncompile is defined.
439 Yeah.
439 This constrains the implementation to save source code somewhere,
which is more of a nuisance than a hardship. This is really another
one of those user convenience things.
440 Sure, with the same proviso as for inline functions, that a macro
call may not be traceable because it's been expanded already.
443 Now we know how to implement apropos! :-)
447 What's another function when you've got hundreds? Sure.
stan
∂13-Dec-85 1215 gls@THINK-AQUINAS.ARPA list of proposed changes to Common Lisp
Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85 12:15:29 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 15:15:17 est
Date: Fri, 13 Dec 85 15:15 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: list of proposed changes to Common Lisp
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851213151511.1.GLS@THINK-JEHOSEPHAT.ARPA>
The following is the text, verbatim, of the handout I made available
this past Monday at the Common Lisp meeting. One exception: in the entry
for page 293, the second occurrence of (DISPLACED-ARRAY-P NEW-ARRAY)
has been deleted because it was a typographical error.
------------------------------------------------------------------------
These are changes that I (Guy Steele) think are important but must not
be made without the general approval of the Common Lisp community.
Items that I think particularly important (because they correct
important flaws or resolve ambiguity in the specification) are marked
(*).
1 DELETE-SETF-METHOD takes the name of an access-fn and removes the SETF
data associated with that name. DELETE-PACKAGE takes a package,
uninterns all symbols in that package, unuses all packages it uses, and
gets rid of the package. An error is signalled if the package is used
by any other package. Maybe other things, such as DELETE-TYPE (undoes a
DEFTYPE), UNDEFUN, UNDEFVAR, UNDEFCONSTANT, and so on are needed as
well. One suggestion is to have a single special form UNDO, allowing
one to write such things as (UNDO DEFUN FOO), (UNDO DEFINE-SETF-METHOD
FOO), and so on (syntax negotiable). Presumably (UNDO SETQ FOO) means
roughly the same as (MAKUNBOUND 'FOO)--or does it? What of the scoping
of FOO? We need some way to do these things, but I have no concrete
suggestion as yet.
(*) 47 Specify that, in a FUNCTION type specifier, following the &KEY
marker one should use items of the form (keyword type-specifier)
instead of just a type-specifier:
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (FROM-END T)
(START (INTEGER 0 ())) (END (INTEGER 0 ()))
(INITIAL-VALUE T))
T)
REDUCE))
Specify that such a declaration implies that no other keywords may be
used unless the declaration also contains &ALLOW-OTHER-KEYWORDS; in
other words, one must explicitly declare types for all keyword arguments
or else use &ALLOW-OTHER-KEYWORDS. Specify that a type specifier for a
&REST argument indicates the type of each argument, not the type of a
rest-argument list (which is always a list, after all):
(DECLARE (FTYPE (FUNCTION (ARRAY &REST (INTEGER 0 ())) T) AREF))
(*) 51 Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time.
(*) 56, 68 Clarify that using DEFCONSTANT to redefine any constant
described in the Common Lisp specification is an error. Clarify that if
the user defines a constant, compiles code that refers to that constant,
and then redefines the constant, then behavior of the compiled code may
be unpredictable. (Perhaps it ``is an error'' to execute such code.)
(*) 60 Specify that it is an error for two parameters (including supplied-p
parameters) in the same lambda-list to have the same (EQL) name. (An
alternative is to say that it is not an error, and the effective binding
order is from left to right, as you would expect from the rules for init
forms. This is no worse than LET*, but somehow does not appeal to me.
A possible compromise is that no two required arguments may have the
same name.)
82 Have a function XOR of any number of arguments that returns T if an
odd number of its arguments are non-NIL, and otherwise returns NIL.
This complements AND and OR (but there is no point in making it a
special form as all arguments must be evaluated).
(*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
not perform macro-expansion on the given form, and that in most contexts
the usage should be (GET-SETF-METHOD (MACROEXPAND form env)). Indeed,
the simplified example version of SETF given on page 108 should be
changed to:
(DEFMACRO SETF (REFERENCE VALUE &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (...)
(GET-SETF-METHOD (MACROEXPAND REFERENCE ENV))
...))
[Alternatively, we could specify that GET-SETF-METHOD should take an
environment as an additional, optional argument, but that would be a
change to the language rather than simply a clarification.]
(*) 113 Permit declarations before the body of a LABELS, FLET, or MACROLET.
(*) 120 In addition to DEFUN, the following macros should implicitly wrap a
BLOCK around their bodies: DEFMACRO, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE. This should be encouraged as a philosophy of style for
user-written macros. Also, LABELS, FLET amd MACROLET should wrap
a block around the bodies of the locally defined functions.
(*) 130 Specify explicitly that anything in a TAGBODY other than a symbol,
integer, or list is an error.
(*) 130 Specify that it is an error for the same (EQL) tag to appear more
than once in the body of a TAGBODY. (However, a TAGBODY may have the
same tag as another TAGBODY in which it nests, in which case the tag in
the outer TAGBODY is shadowed, as already specified.)
(*) 144 Delete the third paragraph of the description of MACRO-FUNCTION,
which specifies that MACRO-FUNCTION cannot be used to access macro
functions defined by MACROLET. Change MACRO-FUNCTION to take an
optional environment argument so that it can get at macros defined by
MACROLET. Specify that when SETF is used with MACRO-FUNCTION, only one
argument may be given to MACRO-FUNCTION.
(*) 145 Add a new function PARSE-BODY, taking arguments body, environment,
and documentation-allowed-p. It pulls apart the body into three parts:
a list of DECLARE forms, a documentation string (or NIL if none), and
the body proper. These are returned in the order body, declarations,
and doc-string as three values. PARSE-BODY may perform macro-expansion
(using the given environment) in order to determine whether a macro-call
expands into a DECLARE form (or documentation string??).
145 Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
&body (body-var [declarations-var [doc-string-var]]). If only body-var
appears in parentheses, it means the same as a body-var with no
parentheses. Otherwise, it means to give the original body to
PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
specified) and then bind the variables to the corresponding values
returned by PARSE-BODY. This is purely a syntactic convenience for the
user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
call PARSE-BODY himself.
(*) 145 Specify that the &REST or &BODY argument to a macro may be the very
list from the macro call, and not a copy, and therefore the user should
not perform destructive operations on it. Similarly, a function that
takes as &REST argument should not destroy it because its top-level list
structure might might share with a list that the user gave as the last
argument to APPLY.
(*) 158 Specify that it is an error for more than one TYPE declaration for a
given variable to appear in a group of declarations (those all at the
head of the same body), or more than one FTYPE or FUNCTION declaration
for a given function name, or both an INLINE and a NOTINLINE declaration
for the same function. Proclamations produce no such conflict; the
most recent proclamation supersedes all others.
(*) 159 Clarify that in the following example
(DEFUN FOO (X)
(DECLARE (INLINE BAR))
(BAR X) ;first
(FLET ((BAR (Z) (BAR (+ Z 1)))) ;second
(BAR X)) ;third
(BAR X)) ;fourth
the first, second, and fourth calls to BAR are affected by the INLINE
declaration, but not the third one.
(*) 159 For consistency with the FUNCTION type specifier, change the
syntax of the FUNCTION declaration to (FUNCTION name arglist result-type)
with a note to the effect that types of multiple values are expressed as
(FUNCTION name arglist (VALUES result-type-1 result-type-2 ...)).
(*) 161 Specify that (THE type form) where type is not (VALUES ...) means
the same as (THE (VALUES type) form), and that in (THE (VALUES ...)
form) the form may return more values, but not fewer, than the number of
types specified in the (VALUES ...), and that any extra values are of
unrestricted type.
(*) 172 Revise the paragraph beginning ``As a verb'' to reflect the fact
that INTERN cannot take a symbol, only a string. One ought to speak of
interning a name in a package, producing a symbol.
186 Modify the definition of IMPORT as follows: if any symbol to be
imported has no home package, then IMPORT sets the home package of the
symbol to the specified package being imported to.
(*) 187 Modify description of DO-SYMBOLS to specify that it may execute the
body more than once for some symbols.
(*) 202 Define (LCM) to return 1 (the manual is incorrect in claiming that
the result should be infinity).
212 Change the branch cuts of the ATAN function to follow W. Kahan's
recommendations. (Paul Penfield intends to recommend the same change to
the APL community.)
226 Add a function SIGNED-LDB that is like LDB but sign-extends the
extracted byte.
239 Change CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP,
CHAR-NOT-LESSP, and CHAR-NOT-GREATERP to consider two characters to be
different if their bits attributes are different.
249 What is the effect of giving circular lists to MAP, MAPCAR, SOME,
EVERY, etc.? Specify that there is an error? Is it good style to write
(MAPCAR \#' CONS X (STAR Y)) for (MAPCAR \#' (LAMBDA (Z) (CONS Z Y)) X)
where (DEFUN START (X) (RPLACD X X) X)? I recommend that this be
considered an error.
268 Have a function COPY that can copy any single object. For a
structure, it would use the user-specified copy function, if any. For a
CONS cell it would copy just that CONS. Whether (EQ X (COPY X)) for X a
character or number is implementation-dependent.
(*) 275 Clarify that (TAILP NIL X) returns NIL for all lists X. The second
sentence in the description of TAILP is incorrect.
283 Functions HASH-TABLE-REHASH-SIZE, HASH-TABLE-REHASH-THRESHOLD,
HASH-TABLE-SIZE, and HASH-TABLE-TEST each take a hash table and return
the appropriate current information.
(*) 293 Add a function ROW-MAJOR-AREF, taking an array and a single
subscript, that accesses an array element according to the row-major
ordering. Add a function DISPLACED-ARRAY-P, which takes an array and
returns NIL and 0 if it is not displaced or the array displaced to and
the displaced-index-offset if it is displaced. These allow certain code
efficiencies, and also allow array displacement to be explained in
terms of Lisp primitives:
(DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS)
(LABELS ((FOO (ARRAY INDEX)
(MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY)
(IF (NULL NEW-ARRAY)
(ROW-MAJOR-AREF ARRAY INDEX)
(MULTIPLE-VALUE-CALL #'FOO
NEW-ARRAY
(+ INDEX OFFSET)))))
(FOO ORIGINAL-ARRAY
(APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS))))
As a bow to efficiency, note the fact that if array A is displaced to B
with offset M, and B is displaced to C with offset N, and B is not
adjustable, then DISPLACED-ARRAY-P of A might return either array B with
offset M or array C with offset (+ M N). This generalizes to chains
of non-adjustable arrays.
(*) 295 Specify that ADJUST-ARRAY is another important exception to the
general rule about operating only on active elements of arrays.
(See proposed clarifications of ADJUST-ARRAY.)
(*) 297 Here are the interactions of ADJUST-ARRAY with displacement.
Suppose we are adjusting array A, which is perhaps displaced
to B before adjustment and perhaps to C after adjustment.
(1) Not displaced before or after. The dimensions of A are altered, and
the contents rearranged as appropriate. Additional elements of A are
taken from the :initial-element. The use of :initial-contents causes
all old contents to be discarded.
(2) Not displaced before, but displaced afterwards to C. As already
specified, none of the original contents of A appears in A afterwards,
but rather the contents of C without any rearrangement of C.
(3) Displaced beforehand to B, and afterward to C. As in case (2), no
contents of B appear in A afterward. If :DISPLACED-INDEX-OFFSET is not
specified in this case, it defaults to zero; the old offset (into B) is
not retained.
(4) Displaced beforehand to B, but not displaced afterward. A gets a
new "data region", and contents of B are copied into it as appropriate
to maintain the existing old contents; additional elements of A are
taken from the :initial-element. However, the use of :initial-contents
causes all old contents to be discarded.
(*) 297 Specify that the fill pointer is ignored for the purposes of
deciding whether a given element of a new array resulting from
ADJUST-ARRAY should take its value from the old array contents or from
the specified :INITIAL-ELEMENT.
(*) 307 Allow a call to DEFSTRUCT to have no slot-descriptions.
(*) 307 Specify that it is an error for two slots in a single DEFSTRUCT
to have the same name. If structure A includes structure B, then
no additional slot of A may have the same name as any slot of B.
(*) 321 Modify EVAL to have an optional environment argument.
(*) 322 At end of second paragraph on *APPLYHOOK*, clarify that the apply
hook function is not used when special forms are evaluated.
(*) 328 Remove the requirement that *STANDARD-INPUT*, etc., must be
initially bound to synonym streams to *TERMINAL-IO*; demote this to the
level of an implementation suggestion. This is to allow flexibility of
implementation, for example to allow UNIX [TM and all the usual
deferences that people for some reason pay to UNIX but not to Kleenex or
Coke or Star Wars] redirection to win. (I don't mind noting the
trademark status of UNIX; it just bugs me that people who do so are not
so consistently diligent about other trademarks.)
425 Generalize FILE-LENGTH to accept any filename, not just an open
file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting
to STRING-CHAR for non-stream arguments and to the element-type of the
stream for a stream argument.
(*) 439 Clarify that if DISASSEMBLE is given a symbol whose function
definition is interpreted, that definition is indeed compiled and
then disassembled, but the resulting compiled definition does not
replace the interpreted one as the symbol's function definition.
439 COMPILEDP takes a function and returns non-NIL if it is a compiled
function, and NIL if it is not. If the function is a symbol whose
compiled-function definition was installed by the COMPILE function, then
the non-NIL value returned is the interpreted definition that was
compiled.
439 UNCOMPILE takes a symbol and restores the previous interpreted
definition of that symbol if that symbol previously had an interpreted
definition and was then given to COMPILE; otherwise no action is taken.
440 Specify explicitly that one may trace macros as well as functions
(but not special forms).
(*) 443 Modify description of APROPOS to replace the words ``available in''
to ``accessible in,'' and specify that APROPOS on a given package finds
the same symbols that DO-SYMBOLS would.
447 The USER-NAME function returns a string identifying the user of the
Common Lisp system, or NIL if that cannot be determined.
∂13-Dec-85 1217 gls@THINK-AQUINAS.ARPA Typographical corrections to Common Lisp book
Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85 12:17:06 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 15:16:58 est
Date: Fri, 13 Dec 85 15:16 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Typographical corrections to Common Lisp book
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851213151656.2.GLS@THINK-JEHOSEPHAT.ARPA>
The following is the text, verbatim, of the other handout I made
available this past Monday at the Common Lisp meeting.
----------------------------------------------------------------------
Corrections to first printing of Common Lisp: The Language
Thanks to the many people who noticed these problems, and
especially to Dr. Masayuki Ida, who found over fifty of them.
-- Guy Steele, December 1985
6 line 4 from bottom: Definition 1-1 => Table 1-1
7 line 2 from bottom: Definition 1-2 => Table 1-2
8 line 3 Definition 1-3 => Table 1-3
8 line 7 Definition 1-4 => Table 1-4
8 line 9 from bottom: Definition 1-5 => Table 1-5
9 line 17 A\( B => A\(B (blank should be deleted)
9 Under \, "a symbol whose name is consists of the" =>
"a symbol whose name consists of the".
10 First two paragraphs should have monospace comma and colon,
respectively, at the left margin.
18 3.1010299957f-1 should be 3.010299957f-1 (first "1" should be deleted).
20 line 1 "#," (bad printing)
35 line 12 "where x is subtype of common" => "where x is a subtype of common"
43 Table 43-1 should include the names "signed-byte" and "unsigned-byte".
44 Delete both compatibility notes.
67 "The defun special form" => "The defun macro"
67 The comment in (defun discriminant ...) is wrong, because the code
works for complex coefficients. Change the line
The quadratic equation a*x↑2+b*x+c=0 has real, multiple
to be the two lines
If the coefficients a, b, and c are all real numbers, then
the quadratic equation a*x↑2+b*x+c=0 has real, multiple
69 Top line, last word but one, should be "replace", not "replaces".
69 Clarify that EVAL-WHEN returns the value of the last form in its body.
73 In the compatibility note, observe that Common Lisp ATOM corresponds
to Interlisp NLISTP.
75 line 5 from bottom: vectorp => simple-vector-p
80 Delete the first compatibility note.
87 Rewrite the second sentence in the description of FUNCTION as
follows: "In particular, if fn is a symbol, then the functional
definition of that name is returned, which is that established by the
innermost lexically enclosing FLET, LABELS, or MACROLET construct, if
there is one, or else the global functional definition of the symbol
(see SYMBOL-FUNCTION)."
92 line 13 setf => psetf
94 line 11 from bottom: "newvalue2)" => "newvalue2"
99 line 8 place => place1
99 In first line of second paragraph, delete the italicized word "newvalue".
108 In the compatibility note, observe that Interlisp APPLY*, unlike
Common Lisp FUNCALL, can be used to apply special forms.
118 In the compatibility note, observe that Interlisp SELECTQ has
a syntax different from that of Common Lisp CASE in having a separate
trailing "else" form.
122 line 2 from bottom: "init" should be italic
122 line 1 from bottom: "var" should be italic
125 Line 9: Delete first sentence and replace with: "As an example of
nested loops, consider a data structure that is a list of conses."
(Remove spurious reference to "env".)
128 Delete compatibility note.
132 line 15 from bottom: "Mismatch-gleep!S" => "Mismatch-gleep!~S"
132 line 2 from bottom: (same as P132 B15L)
145 Three lines from the bottom, the term "&environment" should
appear at the left in monospace.
147 Last line on this page should be deleted; it duplicates first line
on page 148.
154 Add to the table of forms allowing declarations in their bodies
WITH-OPEN-STREAM, WITH-OPEN-FILE, WITH-OUTPUT-TO-STRING, and
WITH-INPUT-FROM-STRING.
157 In third line, "declaration-form" should be "decl-spec" (in italics).
159 After the line "... entirely equivalent to" the next line should read
(ftype (function arglist (values result-type-1 result-type-2 ...)) name)
189 In the code comments, "just a few thing" => "just a few things".
190 In LEAD-TO-GOLD, "(phlogiston:heat-flow x)" =>
"(phlogiston:heat-flow 1/137 x x)".
191 Before HEAT-FLOW definition, insert "(DEFVAR *FEELING-WEAK* NIL)"
and rename FEELING-WEAK => *FEELING-WEAK*. (Actually, maybe we can come
up with a more realistic example of two modules for the next edition.)
200 At the end of the first paragraph "returns the result." add the sentence
"It is an error if any argument other than the first is zero."
After "With one argument, / reciprocates the result" add the sentence
"The argument must not be zero."
204 Halfway down, the last line of a paragraph "#C(0.5 1.73205)."
should say "#C(1.0 1.73205)."
205 line 7 from bottom: "x" should be italic
206 line 5 "number" should be italic
206 line 7 "x" should be italic
209 Delete the last two sentences of the compatibility note, as the
information about Interlisp is not (or is no longer) correct.
214 line 1 from bottom: "x" should be italic
215 line 2 "x" should be italic
216 Alter "The divisor may be any non-complex number." to read
"The divisor may be any non-zero non-complex number."
216 Change "For example, (floor 5 2) @EQ (floor (/ 5 2)) ..." to
"For example, (values (floor 5 2)) @EQ (values (floor (/ 5 2))) ...".
[Actually, it would be better to rewrite this whole section, but this
fix at least makes it accurate.]
216 Before last paragraph, insert this new paragraph:
Note that while (floor 5 2) and (floor (/ 5 2)) return the same first
value, they return different remainders as the second value:
(floor 5 2) => 2 1
(floor (/ 5 2)) => 2 1/2
This is why @f[values] was used above in the remark that
(values (floor 5 2)) @EQ (values (floor (/ 5 2))).
222 Occurrences of "logiorc1" and "logiorc2" should be "logorc1" and
"logorc2".
226 In definition of haipart, the occurrence of "n" should be "count".
227 line 8 from bottom: "dpb" => "deposit-field"
230 In second line of description of make-random-state, the
occurrence of random-state should be make-random-state.
246 line 13 "item" and "seq" should be italic, and "seq" => "sequence"
265 line 12 "'a b c" => "'a 'b 'c"
276 Halfway down, in the display line before "See pushnew.", the phrase
"(fn item)" should be "(funcall fn item)", with "funcall" in monospace
and "fn" and "item" in italics as before.
283 In the last sentence of the compatibility note, replace the last
clause with "and in Common Lisp the cases of NIl as a value and no
entry in the hash table can be distinguished."
284 "means the approximately the same as" => "means approximately the
same as"
287 In the last line, :type should be :element-type.
295 In example use of bit-andc1, result should be #*0010, not #*0100.
297 Clarify that if an array with a fill pointer is adjusted and no new
:FILL-ARRAY specification is given, or one is given with the value T,
then the fill pointer retains its old value. It is an error to adjust
the array to be smaller than the (old or explicit new) fill pointer.
If one specifies :FILL-POINTER NIL explicitly to ADJUST-ARRAY, then it
is an error if the array to be adjusted does have a fill pointer.
301 Change the compatibility note to "string= is similar to the
Interlisp function strequal."
307 In the header line for "defstruct", "{slot-description}+" should
be "{slot-description}*" (star instead of plus).
309 First paragraph should end "see section 19.6)." not "see section 19.6.";
there is a missing parenthesis.
315 Under ":type list", ":unnamed" => "not :named".
323 line 19 "applications." => "applications,"
324 In the second and third lines, replace "2" with "3".
325 The name of the variable "-" does not appear in the header line.
344 In the compatibility note, delete the reference to the Interlisp
RADIX function, and move it to page 372 as a comment on the
*print-radix* variable.
348 line 1 horizontal line should be moved to before compatibility note.
347-348 The page layout is a bit confused here; some connection should
be made between the description of ";" and the example.
349 Before the first complete paragraph, there should be a heading
line consisting of a single monospace backquote (accent grave).
349 In the first example of the use of backquote, the character
just before " (print ,x)" is a "t". (It is badly printed in several
copies.)
357 All occurrences of "constructor macro" should read "constructor function".
365 "The user is encouraged to" => "The user may, for some applications,
wish to".
373 Third and sixth lines from bottom: "print-array" in monospace should
be "*print-array*".
394 "~Scale factor" => "~%Scale factor"
394 "(- k 5) 3.14159))" => "(- k 5) (- k 5) 3.14159))"
396 Fourth line: "x x x))" => "x x x x))"
396 Line 12: "314.2$+10" => "314.0$+10" and "3.14L+12" => "3.14E+12"
412 line 20 version. => version).
422 Observe that if :IF-EXISTS NIL or :IF-DOES-NOT-EXIST NIL is used
with WITH-OPEN-FILE then the variable may be bound to NIL, and the
body should test for this case before attempting to use the stream.
430 The sixth line on the page should be "(funcall fn)", not "(funcall fn))".
432 "*break-on-warnings" should be "*break-on-warnings*" (in the heading
for that item).
437 The first argument to CCASE should be called "keyplace", not "keyform".
440 line 3 [function] in the right margin.
449 Replace reference 9 with a reference to the following:
IEEE Standard for Binary Floating-Point Arithmetic
ANSI/IEEE Std 754-1985 (approved July 26, 1985)
IEEE, 345 E 47 St. NY, NY 10017 (stock number SH10116 price $6.50)
452 right column, line 27 from bottom: (entry for characters,
macros) 246-351 => 346-351
454 In index entry for "defun", first page number should be 67, not 57.
458 Entry for function "keyword" should be for "keywordp".
458 First reference for "macrolet" should be 113-114, not 93-94.
459 Add index entry "newline 20, 21-22, 235, 243, 336, 347, 378, 383, 384,
397".
459 left column, line 19 from bottom: "parsing" => "passing"
459 left column, line 9 from bottom: 1325 => 135
461 right column, column, line 18 from bottom: replacd => rplacd
462 First reference to "shadow function" should be 186-187, not 182-183.
463 left column, line 26 from bottom: 382;420 => 332;420
463 left column, line 21 from bottom: comparison 300-306 => 300-302
464 "unread char function" => "unread-char function"
465 right column, line 11 ~: => ~|
465 right column, line 12 :~ => ~;
465 right column, line 20 from bottom: >E => ~E
465 right column, line 19 from bottom: >F => ~F
[END]
∂13-Dec-85 1320 gls@THINK-AQUINAS.ARPA Clarification Comments (long)
Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85 13:19:55 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 16:19:46 est
Date: Fri, 13 Dec 85 16:19 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Clarification Comments (long)
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8512131955.AA23353@utah-orion.ARPA>
Message-Id: <851213161945.4.GLS@THINK-JEHOSEPHAT.ARPA>
A few comments on the comments from SHEBS:
47 This is OK, although it feels a little uncomfortable to include the
name of a local keyword variable in a proclamation that may be in
another file. Bye bye alpha conversion...
The example was poorly chosen. The name of the local keyword variable
can be anything, but is normally the same (but in a different package)
as the name of the keyword that the caller needs to use. Perhaps the
example should have read
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (:FROM-END T)
(:START (INTEGER 0 ())) (:END (INTEGER 0 ()))
(:INITIAL-VALUE T))
T)
REDUCE)
Now that I think of it, I was trying to follow the rule that the
declaration should look like the parameter list, but with types
substituted for the variable names and with init forms (and supplied-p
parameters) omitted. It is tempting to use the flatter syntax
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY :FROM-END T
:START (INTEGER 0 ()) :END (INTEGER 0 ())
:INITIAL-VALUE T)
T)
REDUCE)
but that confuses call syntax with parameter-list syntax. Now that I have
enunciated the principle, I now see that the truly consistent syntax
is not either of the two example above; to match parameter-list syntax
exactly another level of parentheses is needed:
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY ((:FROM-END T))
((:START (INTEGER 0 ()))) ((:END (INTEGER 0 ())))
((:INITIAL-VALUE T)))
T)
REDUCE)
These extra parentheses could be unambiguously elided in type specifiers,
but the corresponding parentheses may not be elided in parameter lists.
130 I didn't realize until now that tagbody does have a restriction
on body contents. That seems wrong to me. Presumably lots of things
will macroexpand into tagbodies, and every one inherits the same
restriction. Worse, one implementation's dolist will macroexpand
into a tagbody, while in another, it will be a special form. Why
not say that integers and symbols are tags, and everything else is
a form? Or that all non-lists are tags?
But all objects other than symbols and lists are either constants or
erroneous when treated as forms. Someone has suggested that strings be
permitted in a TAGBODY as comments. I don't think we want
floating-point tags.
186 Doesn't seem *wrong*, but not clear why one can't explicitly test
symbol-package and intern instead. Sounds like a frob.
INTERN cannot take a symbol, only a string.
239 This one seems really unmotivated - why the bits and not the
font anyway? Perhaps we could add keywords to char comparison
to tell which parts of the char are to be considered :-)
The book already specifies that the fonts may or may not be
examined, depending on the implementation, and an example is
given to explain why.
439 This constrains the implementation to save source code somewhere,
which is more of a nuisance than a hardship. This is really another
one of those user convenience things.
Yes, it's "just" a convenience. Only COMPILE is so constrained; files
produced by COMPILE-FILE are not required to retain the source code
as well for later loading.
440 Sure, with the same proviso as for inline functions, that a macro
call may not be traceable because it's been expanded already.
Good point.
∂13-Dec-85 1401 shebs%utah-orion@utah-cs.arpa Re: Clarification Comments (long)
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 14:01:26 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA02288; Fri, 13 Dec 85 15:01:05 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA24274; Fri, 13 Dec 85 15:00:55 MST
Date: Fri, 13 Dec 85 15:00:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8512132200.AA24274@utah-orion.ARPA>
To: gls@aquinas.think.com
Subject: Re: Clarification Comments (long)
Cc: common-lisp@su-ai.arpa
Comments on comments on comments on clarifications:
Date: Fri, 13 Dec 85 16:19 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
47 This is OK, although it feels a little uncomfortable to include the
name of a local keyword variable in a proclamation that may be in
another file. Bye bye alpha conversion...
The example was poorly chosen. The name of the local keyword variable
can be anything, but is normally the same (but in a different package)
as the name of the keyword that the caller needs to use. Perhaps the
example should have read
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (:FROM-END T)
(:START (INTEGER 0 ())) (:END (INTEGER 0 ()))
(:INITIAL-VALUE T))
T)
REDUCE)
Now that I think of it, I was trying to follow the rule that the
declaration should look like the parameter list, but with types
substituted for the variable names and with init forms (and supplied-p
parameters) omitted. It is tempting to use the flatter syntax
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY :FROM-END T
:START (INTEGER 0 ()) :END (INTEGER 0 ())
:INITIAL-VALUE T)
T)
REDUCE)
but that confuses call syntax with parameter-list syntax. Now that I have
enunciated the principle, I now see that the truly consistent syntax
is not either of the two example above; to match parameter-list syntax
exactly another level of parentheses is needed:
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY ((:FROM-END T))
((:START (INTEGER 0 ()))) ((:END (INTEGER 0 ())))
((:INITIAL-VALUE T)))
T)
REDUCE)
These extra parentheses could be unambiguously elided in type specifiers,
but the corresponding parentheses may not be elided in parameter lists.
I like the last solution (without the extra parens!).
130 I didn't realize until now that tagbody does have a restriction
on body contents. That seems wrong to me. Presumably lots of things
will macroexpand into tagbodies, and every one inherits the same
restriction. Worse, one implementation's dolist will macroexpand
into a tagbody, while in another, it will be a special form. Why
not say that integers and symbols are tags, and everything else is
a form? Or that all non-lists are tags?
But all objects other than symbols and lists are either constants or
erroneous when treated as forms. Someone has suggested that strings be
permitted in a TAGBODY as comments. I don't think we want
floating-point tags.
After poring over the book, it seems that it is specified as to which things
have tagbodies and which do not. I have no problem with this clarification
then.
186 Doesn't seem *wrong*, but not clear why one can't explicitly test
symbol-package and intern instead. Sounds like a frob.
INTERN cannot take a symbol, only a string.
OK, OK, so I left out a step... I still don't understand why import needs
extra features - is it just to prevent what would otherwise be an error?
239 This one seems really unmotivated - why the bits and not the
font anyway? Perhaps we could add keywords to char comparison
to tell which parts of the char are to be considered :-)
The book already specifies that the fonts may or may not be
examined, depending on the implementation, and an example is
given to explain why.
Now that I look at the book, it all makes sense. Yes, bits should be
considered, in an implementation-dependent manner.
stan
∂13-Dec-85 1606 REM%IMSSS.#Pup@SU-SCORE.ARPA What about advising special forms?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 16:06:17 PST
Received: from IMSSS by Score with Pup; Fri 13 Dec 85 15:46:50-PST
Date: 13 Dec 1985 1545-PST
From: Rem@IMSSS
Subject: What about advising special forms?
To: COMMON-LISP%SU-AI@SCORE
A common debugging technique is to advise a function by splicing some
I/O code or case-checking code between the function name and the code
in its function cell. The most common example is tracing a function.
One common implementation is to make up a funny name and copy the code
pointer into that new function cell, and then make the original function
cell point to a piece of code that does the advising and calls the
new-name function. Are we saying in CL we can't ever advise (trace etc.)
a special operator because we can't be sure that
(SETF (FUNCTION-CELL 'FUNNY-NAME) (FUNCTION-CELL 'ORIGINAL-SPECIAL-OPERATOR))
will work at all in the interpretor?
-------
∂13-Dec-85 1703 Moon@SCRC-STONY-BROOK.ARPA Re: Special Form Question
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 17:02:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374163; Fri 13-Dec-85 19:26:59-EST
Date: Fri, 13 Dec 85 19:22 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Special Form Question
To: NGALL@BBNG.ARPA
cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <[BBNG.ARPA]13-Dec-85 13:56:25.NGALL>
Message-ID: <851213192202.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 13 Dec 1985 13:56-EST
From: NGALL@BBNG.ARPA
....If this "strange object" is to be completely unspecified, then the
section of the defintion of special-form-p (pg. 91) that DOES specify
what this strange object "typically" is, should be made an
Implementation Note.
special-form-p is not the same function as symbol-function and does not
(necessarily) return the same strange unspecified objects.
∂13-Dec-85 1846 FAHLMAN@C.CS.CMU.EDU What about advising special forms?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85 18:46:32 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Dec 85 21:46:17-EST
Date: Fri, 13 Dec 1985 21:46 EST
Message-ID: <FAHLMAN.12166919735.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Rem @ MIT-MC.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: What about advising special forms?
In-reply-to: Msg of 13 Dec 1985 18:45-EST from Rem at IMSSS
Are we saying in CL we can't ever advise (trace etc.)
a special operator because we can't be sure that
(SETF (FUNCTION-CELL 'FUNNY-NAME)
(FUNCTION-CELL 'ORIGINAL-SPECIAL-OPERATOR))
will work at all in the interpretor?
We are saying that the ability to advise (trace etc) special forms is
not something that you can do in a strictly portable way, depending on
the above sort of replacement. Implementations that want to provide
this facility are free to do this if it happens to be feasible. One
cannot just call the normal TRACE function on a special form in any
event, since the handling of arguments is different and since the trace
is liable to get into an infinite loop if you don't take some care to
prevent this. So I see no great loss in saying that this case will not
work in general.
-- Scott
∂13-Dec-85 1903 FAHLMAN@C.CS.CMU.EDU Re: Special Form Question
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85 19:02:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Dec 85 22:02:13-EST
Date: Fri, 13 Dec 1985 22:02 EST
Message-ID: <FAHLMAN.12166922635.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Re: Special Form Question
In-reply-to: Msg of 13 Dec 1985 13:56-EST from NGALL@BBNG.ARPA
I think the best position to take is the following: Symbols that name
special forms do have symbol-function slots, just like any other symbol.
Wrong. A CL symbol does not have a function as a "user-visible
component" (i.e., slot; cf. pg. 163). Since CLtL goes out of its way
to point this out, I think it is a good idea to not slip back into
definition by implementation (are any implementtations NOT using
function cells?).
All right, on page 163 it says that Symbol-function is not necessarily a
slot in the symbol object, but on page 90 it says that symbol-function
returns an object that "may be a function or may be an object
representing a special form or macro". However, it is an error if you
try to invoke an object of the latter kind as a function. I think that
this is consistent with the behavior I suggested, though I should not
have referred to Symbol-Function as fetching something from a slot.
If we decide to go with this description of the required behavior, some
wording on page 9 needs to be clarified. It says that a error IS
SIGNALLED if you do Symbol-Function on a symbol with no funciton
definition, but then seems to indicate that this error would not be
signalled if the definition is a macro or special form. Alternatively,
we could specify that the error is signalled unless the symbol defines a
function in the strict sense, but if we do that a lot of implementaitons
would have to be fixed in ways that might hurt efficiency.
-- Scott
∂13-Dec-85 2146 RAM@C.CS.CMU.EDU list of proposed changes to Common Lisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85 21:46:35 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sat 14 Dec 85 00:46:29-EST
Date: Sat, 14 Dec 1985 00:46 EST
Message-ID: <RAM.12166952525.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: list of proposed changes to Common Lisp
In-reply-to: Msg of 13 Dec 1985 15:15-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
(*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
not perform macro-expansion on the given form, and that in most contexts
the usage should be (GET-SETF-METHOD (MACROEXPAND form env)). Indeed,
the simplified example version of SETF given on page 108 should be
changed to:
(DEFMACRO SETF (REFERENCE VALUE &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (...)
(GET-SETF-METHOD (MACROEXPAND REFERENCE ENV))
...))
[Alternatively, we could specify that GET-SETF-METHOD should take an
environment as an additional, optional argument, but that would be a
change to the language rather than simply a clarification.]
This won't work, as it prohibits defining setf methods for macros.
GET-SETF-METHOD needs the environment so that it can expand macros one
level at a time, checking if the result has a setf method. I also
suggest that the environment argument not be optional, as any user
code which doesn't supply it is surely broken.
268 Have a function COPY that can copy any single object. For a
structure, it would use the user-specified copy function, if any. For a
CONS cell it would copy just that CONS. Whether (EQ X (COPY X)) for X a
character or number is implementation-dependent.
What does this function do in the presence of displaced and adjustable
arrays? Are these attributes preserved, or is the result just
structurally identical? How about a COPY-ALL function which descends
into structure until it finds something not needing to be copied?
I have some of my own unclarities and clarifications:
If we're allowed to clarify things by adding new functions, then I
propose my own: a structural equality predicate. It descends into
arrays and structures, but compares leaves with EQL. This is what
EQUAL should have been, but couldn't for hysterical reasons.
("Descending into arrays is too inefficient.", to which I reply "Not
if you want to compare arrays.") As far as equality predicates go,
arrays are still second-class citizens of the language.
312 It should be explicitly noted somewhere that defstruct copiers
work on structures which are a subtype by inclusion, e.g. COPY-PERSON
works on an astronaut. This is a natural consequence of the subtype
semantics of inclusion, but isn't necessarily obvious to pea-brained
implementors.
416 I think that the DEFAULTS argument to MAKE-PATHNAME should be
allowed to be an arbitrary thing, rather than being constrained to
being a pathname. All other pathname args can be any thing accepted
by PATHNAME.
413,424 The semantics of TRUENAME and PROBE-FILE on open streams
needs to be clarified. The requirement that PROBE-FILE never return
NIL on an open file is clearly broken. Spice Lisp currently
implements TRUENAME and PROBE-FILE in the same way, except that
TRUENAME errors instead of returning NIL. Someone (Moon, I believe)
suggested that (PROBE-FILE <stream>) was the same as
(PROBE-FILE (PATHNAME <stream>)), but that (TRUENAME <stream>) was
somehow different. There also needs to be some discussion of the
meaning of operations on closed streams. The manual never says which
operations may be done on closed streams, let alone what the
operations do.
410 There should be some clarification of what can be expected from
implementations where some of the pathname components are meaningless,
i.e. host and version. Must these fields actually exist in the
pathname object? What must the operations do with these fields?
419 Are implementations really required to support all those element
types? (signed-byte 1234567)? I guess arbitrary restrictions would
be allowed by the implementation note on 421, but it doesn't really
apply here. It is possible in any filesystem to implement I/O of all
these things. The question is whether it's worth the effort.
419 I believe that everyone agreed that :DIRECTION :PROBE was silly
and should be flushed.
438 There should be some discussion of the semantics of compilation on
literal constants (things appearing in quoted structure in code).
1] What types of objects may be constants? Surely not any, as some
implementations find it impossible to dump things such as compiled
function objects.
2] To what degree is sharing and non-sharing preserved? Many
implementations both introduce and remove sharing. Probably most
don't dump circular structures.
3] How does symbol dumping and loading work?
Since the reference model for compilation is that "it may run faster",
it seems that ideally the semantics of loading a compiled file should
be indentical to those of loading the source. This goal is
unrealistic, since the reading of the source by the compiler loses
information. A better model is that compilation and loading should be
similar to printing and reading again. This is probably excessively
restrictive, but may also be too liberal in that it suggests that
circular structures can be dumped.
Rob
∂14-Dec-85 1752 edsel!eb@su-navajo.arpa Undoing global side-effects
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 17:52:27 PST
Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 17:49:43 pst
Received: by edsel.uucp (2.2/SMI-2.0)
id AA01705; Sat, 14 Dec 85 17:40:07 pst
Date: Sat, 14 Dec 85 17:40:07 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8512150140.AA01705@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: Undoing global side-effects
I went through the Common Lisp manual looking for functions which have
global side-effects and came up with the following list, along with
suggested functions for removing those side effects:
PROCLAIM SPECIAL
DEFVAR
DEFPARAMETER
These should all be undoable by MAKUNBOUND and an UNSPECIAL
proclamation. UNSPECIAL should be restricted to use in PROCLAIM and not
allowed in DECLARE. This will prevent a major incompatible change in
declaration processing.
DEFCONSTANT
DELETE-CONSTANT should make a symbol unbound, unspecial and
inconstant (yes, it's a real English word).
DEFUN
DEFMACRO
SETF of SYMBOL-FUNCTION
SETF of MACRO-FUNCTION
These are undone by FMAKUNBOUND. In some implementations, DEFUN and
DEFMACRO record information other than the function definition. Since
this is outside the scope of Common Lisp, the language standard need not
include a way to undo it.
DEFSETF
DEFINE-SETF-METHOD
These are undone by the DELETE-SETF-METHOD function previously
described.
DEFTYPE
The DELETE-TYPE function should undo this. It should signal an error
if any other type is a subtype of the specified type. It "is an error"
to DELETE-TYPE any of the built-in Common Lisp types.
DEFSTRUCT
There ought to be a DELETE-DEFSTRUCT function which undoes all the
effects of the DEFSTRUCT, by removing all function definitions
(including compiler database entries for inline compilation), removing
any type database entry, removing the :PRINT-FUNCTION entry, and
removing any information from DEFSTRUCT's own database (that which
allows a name to be used in the :INCLUDE option). It should signal an
error if any other structure type has :INCLUDEd the given type (unless
that structure type has also been deleted).
MAKE-PACKAGE
This is undone by the DELETE-PACKAGE function previously described.
SHADOW
Document the fact that SHADOW can be undone by UNINTERN, causing any
otherwise inherited symbol to become accessible again.
SETF of DOCUMENTATION
SET-MACRO-CHARACTER
SET-DISPATCH-MACRO-CHARACTER
These should all be undoable by using NIL as the new value. This must
be documented.
Thus there are five new functions
DELETE-PACKAGE
DELETE-SETF-METHOD
DELETE-CONSTANT
DELETE-TYPE
DELETE-DEFSTRUCT
and one new proclamation, UNSPECIAL. It doesn't seem to me to be worth
inventing some new SETF-like meta-deletion macro to handle these. If we
like this naming convention it might a good idea to add the names
DELETE-VALUE and DELETE-FUNCTION as synonyms for MAKUNBOUND and
FMAKUNBOUND, eventually phasing out the latter names.
∂14-Dec-85 1953 edsel!eb@su-navajo.arpa Questions, comments and clarifications on clarifications
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 19:53:24 PST
Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 19:50:34 pst
Received: by edsel.uucp (2.2/SMI-2.0)
id AA01849; Sat, 14 Dec 85 18:30:16 pst
Date: Sat, 14 Dec 85 18:30:16 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8512150230.AA01849@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: Questions, comments and clarifications on clarifications
82. Is it gratuitous pseudo-generality to allow an arbitrary number of
arguments to XOR, instead of requiring exactly two? Give an example.
107. GET-SETF-METHOD should definitely take an optional environment
argument. Calling MACROEXPAND is seldom a good thing to do in a
program, even a compiler, since there may be intermediate macros which
require special handling. In this case an intermediate macro may have a
setf method. Even though a user program is probably incorrect if it
does not supply the environment argument to GET-SETF-METHOD, we should
make it optional for maximum compatibility with the existing standard.
Along with allowing an optional environment argument to GET-SETF-METHOD,
it is important to allow DEFINE-SETF-METHOD to take an &ENVIRONMENT
argument. It is also important that macros defined with
DEFINE-MODIFY-MACRO correctly pass the environment to GET-SETF-METHOD;
this belongs in an implementation note.
A hard question: Does MACROLET shadow a setf method or not?
(DEFUN LOSER (X)
(CAR X)
(DEFUN SET-LOSER (X Y)
(SETF (CAR X) Y))
(DEFSETF LOSER SET-LOSER)
(DEFUN LOSSAGE (X Y)
(MACROLET ((LOSER (X)
`(SYMBOL-VALUE ,X)))
(SETF (LOSER X) Y)))
Does LOSSAGE call SET-LOSER or SET?
130. I think it is better to say that anything other than a symbol or
an integer at the top level in a TAGBODY is evaluated normally, rather
than having special rules. This is not a major point, however.
144. Can an FLET shadow a DEFMACRO?
(DEFMACRO FOO ()
)
(DEFUN BAR ()
(FLET ((FOO () ...))
(MACROLET ((BAZ (&ENVIRONMENT ENV)
(IF (MACRO-FUNCTION 'FOO ENV)
"Lose"
"Win")))
(BAZ))))
Does (BAR) return "Win" or "Lose"? (See if you can guess what I think
it should do.)
268. There's no need to mention that COPY uses the user-specified copy
function for structures, since the user only specifies a @i(name) for the
function; the system supplies the definition.
Along the same lines, there really should be a true structural equality
comparison function, i.e. a case-sensitive EQUALP, or EQUAL which
descends into arrays and structures. It would also be nice to have a
graph isomorphism comparison function, but perhaps this is beyond the
scope of Common Lisp. I only brought it up because it cannot be written
portably so that it descends into all structures. How about graph
isomorphism modulo gensyms?
293. ROW-MAJOR-AREF should be SETFable.
295. Also include SETF of AREF, ROW-MAJOR-AREF, and SETF of
ROW-MAJOR-AREF among the functions which can access beyond the fill
pointer of an array.
∂14-Dec-85 1953 edsel!eb@su-navajo.arpa More clarifications
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 19:53:28 PST
Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 19:50:43 pst
Received: by edsel.uucp (2.2/SMI-2.0)
id AA01946; Sat, 14 Dec 85 18:55:35 pst
Date: Sat, 14 Dec 85 18:55:35 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8512150255.AA01946@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: More clarifications
Here are a couple more items which should be included in the
clarifications:
In the description of FUNCTIONP (p. 76) it says that FUNCTIONP is always
true of symbols. Shouldn't that be changed to say that FUNCTIONP is
true of symbols for which FBOUNDP is true?
In the description of Decoded Time format (p. 444), the Time-zone
component is required to be an integer which is the number of hours west
of GMT. (The latest term is Coordinated Universal Time, or UTC, by the
way). Since time zones are not always an integral number of hours west
of GMT, this should be changed to either (a) a non-complex, non-negative
number which is the number of hours west of GMT, or (b) an integer which
is the number of {minutes, seconds} west of GMT. My personal preference
is for (b) for ease of implementation, but (a) might be preferable for
compatibility with the existing standard. On the other hand, most
programs dealing with time will probably want to deal with integral time
units. Having the time zone bias introduce a ratio or a float by
contagion is probably undesirable. Because of this, and because
Universal Time is defined in units of seconds, I believe the best course
is (b) with seconds, in spite of the incompatibility. (There are 86400
seconds in 24 hours.)
∂15-Dec-85 1155 RAM@C.CS.CMU.EDU Another omission: global lexicals
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 11:53:31 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 14:53:24-EST
Date: Sun, 15 Dec 1985 14:53 EST
Message-ID: <RAM.12167368856.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals
It is truly silly that there is no way to define a global lexical
variable in Common Lisp. Many places where defvar is used there is no
need for dynamic binding, since the variable is never bound. If a
variable is known to be a global lexical then various optimizations
can be made which are otherwise impossible:
1] A global lexical cannot be unbound, therefore there is no need to
check that is bound before accessing it.
2] Since it cannot be globally rebound, there is no need to search
for the value in an implementation which deep-binds specials.
This is significant since shallow-binding doesn't work in
multi-processor implementations.
A global lexical is also less dangerous to use than a global
special, since a global lexical doesn't magically specialify other
lexical uses of the same name. Dynamic binding is overkill in many
applications. I believe that programs would be clearer if it was more
obvious which variables are actually bound dynamically.
It is also worth noting that it should be trivial to add global
lexicals to any implementation. The value is kept in the global value
cell, just as for a special; the only difference is that there is no
special annotation.
I suggest this syntax: DEFGLOBAL <name> <value> [<doc-string>]
Rob
∂15-Dec-85 1322 RPG [Richard Acuff <Acuff@SUMEX-AIM.ARPA>: Summary of Common Lisp meeting]
∂14-Dec-85 1906 ACUFF@SUMEX-AIM.ARPA [Richard Acuff <Acuff@SUMEX-AIM.ARPA>: Summary of Common Lisp meeting]
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 19:06:27 PST
Date: Sat 14 Dec 85 19:06:20-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: [Richard Acuff <Acuff@SUMEX-AIM.ARPA>: Summary of Common Lisp meeting]
To: rpg@SU-AI.ARPA
Message-ID: <12167185537.54.ACUFF@SUMEX-AIM.ARPA>
Ok, here it is. I'd appreciate any corrections or additions. This
is rather thrown together, so pardon bad spelling and grammer.
-- Rich
---------------
Mail-From: ACUFF created at 13-Dec-85 16:23:58
Date: Fri 13 Dec 85 16:23:54-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Summary of Common Lisp meeting
To: common-lisp@SUMEX-AIM.ARPA
Message-ID: <12166893822.45.ACUFF@SUMEX-AIM.ARPA>
The following is a report on the Common Lisp meeting held in Boston
from 9-Dec-85 to 11-Dec-85. The following issues were addressed:
charter and validation, object oriented programming, error handling, and
windows. I will attempt to summarize the sessions, though it is likely
that I've missed something. If you have particular interest in one of
the areas, please contact Dick Gabriel (RPG@SAIL) to be placed on the
appropriate mailing list. Also, all of the documents mentioned herein
are available for copying from me.
Charter
-------
It was decided that the "gang of five", Guy Steele, Dick Gabriel,
Scott Fahlman, David Moon, and Dan Weinreb, plus Steve Squires of DARPA
and Bob Mathis (worked on ADA standardization and is familiar with ISO),
would start the task of moving Common Lisp (CL) towards ISO
standardization. This was felt necessary in order to make Common Lisp
the international standard, especially since the French were proposing
an alternate Lisp standard. This ad hoc committee is to set up and
charter a strategy committee which will work towards the above mentioned
standardization, and set policy for revision and interpretation of the
current language manual. Another committee will be formed to see that
services needed by the CL community, such as maintaining a library (the
"yellow pages"), performing validation, distributing information,
maintaining archives, etc. Discussion of these issues will continue on
the CL Charter mailing list.
Guy Steele distributed two documents of interest. One is a list of
clear cut corrections to "Common Lisp the Language". The other is a
list of clarifications that Guy is proposing.
Validation
----------
After much discussion, almost all vendors present agreed to
contribute the code that they have developed for testing Common Lisp to
a validation and testing suite which is to be administrated via ISI.
Also, most vendors agreed to take a piece of the manual and implement
testing for parts of the language specified in that piece. Discussion
of this will continue on the CL Validation mailing list.
Object Oriented Programming
---------------------------
Three presentations were made. David Moon of Symbolics described New
Flavors, which features advanced method combination and is different
from the flavors system Symolics is now selling. Gregor Kiczales of
Xerox PARC described Common Loops, which features multi-methods (which
method gets invoked is a function of more than one object) and meta
classes. Alan Snyder of Hewlett-Packard presented Common Objects, which
features good modularity between classes (flavors) and is efficient on
stock hardware.
There seemed to be good consensus amoung the various proposers that
none of the systems necessarily precluded features in the others, and it
looked likely that further discussion would lead to a synthesis which
all could agree upon, since all proposals seemed to have the same basic
functionality including integration with the CL type system, multiple
inheritance, slots, method combination, etc. This discussion is to go
on via the CL Objects mailing list. I also have copies of the handouts
that accompanied each of the presentations available for copying.
Concretely, it was proposed, and accepted, that proposers should make
available a mostly portable version of their systems to the CL community
by April to allow experimentation. Further decsions are to be made at
the Lisp Conference in August.
Error Handling
--------------
Kent Pittman of Symbolics, chair of the Errors subcommittee,
presented a third generation proposal for an error handling system,
which seemed to be accepted, though no action was taken. The proposal
includes mechanism for defining condition objects, establishing handlers
for conditions, and signalling them. I have a copy of the proposal
available for copying.
Windows
-------
Lucid and Intellicorp have been collaborating on a design for a window
system and made a presentation on their work. The goals seem to be to
have a powerful, flexible interface specification so that a CL window
system can live on top of a variety of vendor window systems (eg. Sun,
Appolo, Vax, Symbolics, Xerox, etc.) that still allows advanced
interaction such as active regions and event triggered methods. Another
goal is to have a small, simple interface (such as Interlisp-D's) so
that sophisticated interfaces can be built up easily when extra hair is
not needed (Scribe was presented as a good analogy). There will be more
discussion of this on the CL Windows mailing list, and I can elaborate a
few details of the work if anyone is interested.
Bob Balzar from ISI presented some work on environments that has been
going on there. They are trying to develop a fileless environment
wherein all data are objects and there are tools for keeping track of
these objects at various levels (eg. modules, definitions), as well as
providing analysis and version tracking. Anyone interested in this work
can contact Balzar@ISI-VAXA.
-- Rich
-------
-------
∂15-Dec-85 1327 DLW@SCRC-STONY-BROOK.ARPA Questions, comments and clarifications on clarifications
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 13:26:58 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374583; Sun 15-Dec-85 16:26:45-EST
Date: Sun, 15 Dec 85 16:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8512150230.AA01849@edsel.uucp>
Message-ID: <851215163501.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sat, 14 Dec 85 18:30:16 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
82. Is it gratuitous pseudo-generality to allow an arbitrary number of
arguments to XOR, instead of requiring exactly two? Give an example.
One could argue that XOR should take an arbitary number of arguments for
symmetry with AND and OR, even if we can't come up with a satisfying
example. Symmetry is important to keep the language self-consistent and
easier to learn.
As long as I'm sending mail, here are a few more quick comments:
249: There continues to be widespread disagreement among the expert
users I know about circular list arguments to mapping functions.
Several feel that it's natural, elegant, and seriously useful. I do not
have any strong personal opinion, and I do not tend to use this style
personally, but I don't think this issue is nearly as clear-cut as many
of the others in "clarifications.text".
268: I suspect that COPY needs to be defined more specifically than it
is in "clarifications.text" before we can decide whether it ought to be
in the language. While I like the basic idea very much, I'm worried
about a number of details. Someone already brought up the question of
whether copying an array means preserving all of its attributes, such as
displacement. If you COPY an interned symbol, is the result interned or
uninterned, and what's the symbol-package? Are the conses of the
property list copied also, or are the property lists shared? What if
you copy a keyword symbol? Can you copy a package, and if so what is
the name of the copy? If you copy a pathname, is the result allowed to
be EQ to the argument? Can you copy a stream object that's open to a
file and positioned 254 characters into the file? Can you copy an
output stream that's in the middle of writing characters to a file that
it's creating itself? If you copy a closure, do you get a new closure
that shares the variable environment with the original, or does the
environment get copied too? What other such issues might there be? I'd
rather not express an opinion on COPY until a more detailed
specification is proposed.
425: A new argument, :ELEMENT-TYPE, to FILE-LENGTH is proposed, but the
proposal doesn't say what it means. I'd like to hear what this argument
is supposed to be defined to mean, expressed in a way that is
implementation-independent in any sense, such that this argument could
ever be used in a portable program and relied upon to do any specific
thing in particular.
439: What is COMPILEDP defined to do if you give it a lexical closure
over a function that is compiled?
439: [The following is not well thought out; I apologize in advance.]
All this stuff about the COMPILE function retaining the interpreted
definition is starting to make me nervous about the line between a
programming language and a programming environment. This, and also the
"how do you undefine an X" issue, point out that the current design is
wavering between trying to be a language specification and trying to be
a programming environment specification. Obviously, in Lisp it's hard
to draw the line. However, we are all assuming that there is some kind
of distinction. To pick an extreme but illustrative example, suppose
there were a purported Common Lisp implementation in which the CAR
function, before returning the car of a cons, printed out some message
on the terminal. Most of us would consider this a violation of the
Common Lisp spec; that is, if I tried to port my program and my program
failed to work because of this message, I'd blame the CL implementation,
not my program. But LOAD is defined in CLtL just as much as CAR is, and
I haven't heard anybody complain that a Lisp is out of conformance with
the standard because LOAD prints out a message. I don't have any
specific constructive suggestions at this time, but I think if we don't
figure this stuff out, we may be letting ourselves in for trouble and
surprising portability problems.
443: Do you also want to say that APROPOS might find some specific
symbols more than once, assuming that 187 is accepted?
∂15-Dec-85 1330 DLW@SCRC-STONY-BROOK.ARPA Another omission: global lexicals
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 13:30:04 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374588; Sun 15-Dec-85 16:29:42-EST
Date: Sun, 15 Dec 85 16:38 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12167368856.BABYL@C.CS.CMU.EDU>
Message-ID: <851215163801.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sun, 15 Dec 1985 14:53 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I suggest this syntax: DEFGLOBAL <name> <value> [<doc-string>]
And what semantics do you suggest? That is, OK, it's lexical, so what
is its lexical scope?
The oft-discussed
(let ((a 4))
(defun foo (x) ...)
(defun bar (y) ...)
)
would be a way to get global lexicals, if it were Common Lisp. The
current manual is ambiguous, or at least vague, about whether this is
construct is part of valid portable Common Lisp or not.
∂15-Dec-85 1341 Moon@SCRC-STONY-BROOK.ARPA XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 13:41:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374601; Sun 15-Dec-85 16:40:32-EST
Date: Sun, 15 Dec 85 16:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: Steele@Aquinas.Think.COM
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <851215163550.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
The XOR function in your list of suggested language improvements
handed out last week was intended to be a joke, wasn't it? I assumed
it was, but other people on the mailing list are taking it seriously,
so I'm asking for clarification.
∂15-Dec-85 1350 RAM@C.CS.CMU.EDU Another omission: global lexicals
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 13:50:03 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 16:49:24-EST
Date: Sun, 15 Dec 1985 16:49 EST
Message-ID: <RAM.12167389974.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals
In-reply-to: Msg of 15 Dec 1985 16:38-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Date: Sunday, 15 December 1985 16:38-EST
From: Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
To: RAM, common-lisp at SU-AI.ARPA
Re: Another omission: global lexicals
The oft-discussed
(let ((a 4))
(defun foo (x) ...)
(defun bar (y) ...)
)
would be a way to get global lexicals, if it were Common Lisp. The
current manual is ambiguous, or at least vague, about whether this is
construct is part of valid portable Common Lisp or not.
This is clearly legal; any implementation which doesn't allow it is
broken. There is some confusion about the meaning "top level forms"
such as PROCLAIM within such a construct, but I don't see any other
problems.
The lexical scope of a global lexical is everything. If you insist on
thinking about it this way, a global lexical is a global special which
isn't special, i.e. bindings of that name are lexical instead of
special. You can also think of a global lexical as being syntactic
sugar for wrapping a let around all the code in the world.
The only issue that seems murky to me is the interaction between
global specials and global lexicals. What happens if you do a
DEFGLOBAL and then a special procalamation on the same name? Is a
global lexical BOUNDP? Can you MAKUNBOUND it?
Rob
∂15-Dec-85 1447 DLW@SCRC-STONY-BROOK.ARPA Another omission: global lexicals
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 14:47:05 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374652; Sun 15-Dec-85 17:46:48-EST
Date: Sun, 15 Dec 85 17:55 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12167389974.BABYL@C.CS.CMU.EDU>
Message-ID: <851215175503.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Oh. OK, I see what you're saying: top level forms, instead of being
considered to be in the null lexical environment as they are now, are
instead considered to be in a particular distinguished unique lexical
environment, the "global" lexical environment. All lexical environments
"inherit from" (whatever) this one. In addition, there is a macro or
special form called DEFGLOBAL that side-effects this global environment
by adding to it a new variable/value pair.
If foo is a global lexical, and your top-level defun function makes a
reference to foo that's free with respect to the defun, then it refers
to the global lexical variable foo. But if your function does a LET of
foo, it gets a new lexical variable, just as if foo had not been in the
global lexical environment at all.
This all seems semantically consistent. One could ask why it's possible
to side-effect this lexical environment when it isn't possible to
side-effect any other lexical environment. I'm not sure that's really
relevant or interesting, but I thought I'd bring it up in case someone
else does think so.
As for your questions "Is a global lexical BOUNDP? Can you MAKUNBOUND
it?", the answers are clearly "No" and "No", just as for any other
lexical variable. If you do (defglobal foo 3) and then do (boundp'foo),
the latter is asking about the symbol foo, which has nothing to do with
the lexical variable. If you (set 'foo 3), the lexical variable is
likewise unaffected. If you do a special proclaimation on the same
name, then all references and LETs and so on will refer to the symbol
(the special variable); the global lexical variable still exists, but
there is no way to get at it. (Except maybe if you make a closure over
it before you evaluate the proclaimation!)
I'll refrain from making any comments about implementation issues, until
we're sure that we have worked out the semantics so that we know what
we're talking about and we are all talking about the same thing.
∂15-Dec-85 1447 RAM@C.CS.CMU.EDU Another Common Lisp unclarity
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 14:47:01 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 17:46:51-EST
Date: Sun, 15 Dec 1985 17:46 EST
Message-ID: <RAM.12167400426.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Another Common Lisp unclarity
While we are discussing issues needing to be resolved, I will drag
out yet another problem which has been discussed in the past. It
would be nice if someone would keep track of these things starting
*now* so that we don't have to iterate N times.
The problem is with the notion of "top level forms" and things
containing a EVAL-WHEN (COMPILE), possibly implicit. Examples of
forms with implicit compiler evaluation are PROCLAIM, DEFMACRO and
DEFCONSTANT. Other possibles are package manipulation.
The question is whether the compile-time action is done when the
form appears in a context where it is not obvious that the form will
ever be evaluated at run time. What happens if the compiler finds this?
(if (oddp (get-universal-time))
(defmacro foo ...)
(defmacro foo ...))
My answer is that the compiler always does the evaluation, no
matter where the forms appears. The manual seems to support this
interpretation. See the definition of EVAL-WHEN on 69 and DEFMACRO on
146. If this is the correct interpretation, then the manual should
say so, possibly illustrating with an example, since this can result
in non-obvious problems, especially for naive users who foolishly
believe that programs do the same thing when compiled as when
interpreted.
There is some question about what to do with the package
functions. Probably they only want to be evaluated when the function
appears "really at top level". We wouldn't want compilation of this
function to die with an unbound-symbol error:
(defun my-export (syms) (export syms "MY-PACKAGE"))
This contradicts the manual, since on page 182 it says that these
functions are implicitly wrapped in an EVAL-WHEN (COMPILE LOAD EVAL).
Rob
∂15-Dec-85 1455 REM%IMSSS.#Pup@SU-SCORE.ARPA Elegant rule for what to copy
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 14:54:53 PST
Received: from IMSSS by Score with Pup; Sun 15 Dec 85 14:52:06-PST
Date: 15 Dec 1985 1449-PST
From: Rem@IMSSS
Subject: Elegant rule for what to copy
To: COMMON-LISP%SU-AI@SCORE
Here's an elegant rule for what to recursively copy and what to stop at
when doing a recusive copy operation. Stop at anything that has an interned
name (whereby READing in that name will give that same object) and recurse
through anything else. The idea is that copying a structure will be the
same as PRIN1ing it out and READing it back in but more efficient.
Thus a named array (does CL have them?) will be a stop point, wheras an
anonymous array will be recursed through. Interned symbols (IDs) will be
stop points, but GENSYMs will be recursed through, with another GENSYM of
exactly the same name replacing it, and with copies of the value and plist
and function. (In that case READing it back in would accidently INTERN all
the former GENSYMs, so COPY is more "right" than PRIN1-READ.)
There's a slight problem for numbers, where you're supposed to recurse through
them but there's nothing much to recurse through, so the elegant rule does
have a little deficiency there.
Of course for circular structure and to-be-preserved shared structure we
have an alternate more expensive printing routine and likewise should have
a more expensive copy routine.
-------
∂15-Dec-85 1503 GJC@MIT-MC.ARPA Another omission: global lexicals
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 15:02:59 PST
Date: Sun, 15 Dec 85 18:05:36 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject: Another omission: global lexicals
To: DLW@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, RAM@C.CS.CMU.EDU
In-reply-to: Msg of Sun 15 Dec 85 16:38 EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].755061.851215.GJC>
Seriously Dan, if you fellows go before the ISO and say that
"The oft-discussed:"
(let ((a 4))
(defun foo (x) ...)
(defun bar (y) ...)
)
is vague with respect to legality in Common Lisp the USA is going to
look pretty wimpy. Maybe it wouldn't be so vague if more implementations
took the extra trouble (or, what is better, the extra level of uniformity
and generality of treatment) to implement it. Certainly anybodies
CL interpreter would have to either be very broken or being going
out of its way to make this not work at top level:
(let ((a 4))
(setf (symbol-function 'foo) #'(lambda (x) ...))
(setf (symbol-function 'bar) #'(lambda (y) ...)))
So whats the big deal about passing the same thing to a compiler?
Some compilers may not compile the lambda expressions, but a user
could rightly say that is a bug, the compiler generating slow code
instead of good machine code.
∂15-Dec-85 1541 RAM@C.CS.CMU.EDU Another omission: global lexicals
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 15:41:38 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 18:41:02-EST
Date: Sun, 15 Dec 1985 18:40 EST
Message-ID: <RAM.12167410294.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals
In-reply-to: Msg of 15 Dec 1985 17:55-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Yes, we seem to be talking about the same thing. I believe you
have the right model for interaction with specials: there is none.
Unfortunately this means that shallow-binding implementations would
have to have separate lexical and special value cells, since you could
do something like this:
(defglobal foo :global)
(let ((foo :special))
(declare (special foo))
(bar))
(defun bar ()
(format t "~S or ~S, take you pick."
foo (locally (declare (special foo)) foo)))
This doesn't mean that your symbol needs another slot though. You
could keep the lexical value cells somewhere else (such as on the
PLIST!!), since you only need to locate the value cell at load time.
Rob
∂15-Dec-85 1608 RPG Name change
∂27-Nov-85 0040 CORK%umass-cs.csnet@CSNET-RELAY.ARPA Name change
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 00:40:30 PST
Received: from umass-cs by csnet-relay.csnet id ba05609; 27 Nov 85 3:12 EST
Date: Tue, 26 Nov 85 17:38 EST
From: "Dan Corkill (413) 545-0156" <CORK%umass-cs.csnet@CSNET-RELAY.ARPA>
To: common-lisp-request@su-ai.ARPA
Subject: Name change
Please change CORK.UMASS@CSNET-RELAY to CMLISP.UMASS@CSNET-RELAY in your
Common Lisp mailing lists. Thanx.
--Dan Corkill
comlsp.dis and clmultl.dis
∂28-Nov-85 0234 rdoty%lumiere%tektronix.csnet@CSNET-RELAY.ARPA Please add Tek to the list
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 28 Nov 85 02:33:51 PST
Received: from tektronix by csnet-relay.csnet id ab18510; 28 Nov 85 5:23 EST
From: rdoty%lumiere%tektronix.csnet@CSNET-RELAY.ARPA
To: rpg@su-ai.ARPA
Cc: rdoty%tektronix.csnet@CSNET-RELAY.ARPA
Received: from lumiere by tektronix with smtp ; 27 Nov 85 21:40:52 PST
Comment: Message received over unauthenticated port at tektronix
Received: by lumiere (5.31/5.14), id AA12035; Wed, 27 Nov 85 21:38:30 PST
Message-Id: <8511280538.AA12035@lumiere>
Subject: Please add Tek to the list
Date: 27 Nov 85 21:38:18 PST (Wed)
Please add common-lisp@tektronix to your distribution list. Thanks.
(add-dis common)
"common-lisp%tektronix.csnet"@csnet-relay
rdoty
Richard A. Doty - Tektronix, Inc., ds 19-333, Beaverton OR 97077.
rdoty@tektronix -or- usenet@tektronix (503)627-6517
∂15-Dec-85 1621 RAM@C.CS.CMU.EDU Minor package unclarity
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 16:21:20 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 19:21:06-EST
Date: Sun, 15 Dec 1985 19:20 EST
Message-ID: <RAM.12167417579.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Minor package unclarity
It says on 177 that "There is no way to inherit the internal
symbols of another package; to refer to an internal symbol, the user
must either make the symbol's home package current, use a qualifier,
or import that symbol into the current package." This not really
true, since a symbol may be internal in some packages and external in
others. The real vaguery is in the phrase "internal symbol"; there is
no such thing. A symbol is only internal with respect to a particular
package.
This may seem like a quibble, but it can cause confusion. Naive
users have enough problems without encouraging misconceptions. It is
a misconception that internalness or externalness is a property of a
symbol. This misconception should be thouroughly stamped out.
Rob
∂15-Dec-85 1631 RPG
∂12-Dec-85 1657 Moon@SCRC-STONY-BROOK.ARPA
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 16:56:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 373439; Thu 12-Dec-85 19:56:44-EST
Date: Thu, 12 Dec 85 19:51 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
To: rpg@SU-AI.ARPA
Message-ID: <851212195148.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Please put me on the cl-charter @ su-ai mailing list if I'm not already
on it. (SAIL doesn't support the EXPN protocol for finding out.)
(add-dis charter)
moon
∂15-Dec-85 1631 RPG Please add `mly-lispm@mit-mc' to cl-error-handling
∂13-Dec-85 0237 MLY@MIT-MC.ARPA Please add `mly-lispm@mit-mc' to cl-error-handling
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 02:37:10 PST
Date: Fri, 13 Dec 85 05:39:47 EST
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject: Please add `mly-lispm@mit-mc' to cl-error-handling
To: cl-error-handling-request@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].752230.851213.MLY>
Thanks⊗
(add-dis errors)
mly-lispm@mit-mc
∂15-Dec-85 1659 RAM@C.CS.CMU.EDU unclarities: defstruct print functions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 16:58:04 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 19:57:50-EST
Date: Sun, 15 Dec 1985 19:57 EST
Message-ID: <RAM.12167424265.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: unclarities: defstruct print functions
Another issue in need of resolution is that of communicating the
current depth in the printing when there are user-defined print
functions. Guy said that what had in mind was that the user would
bind *print-level* according to the depth arg supplied to the print
function, but there were several problems with this. Most of the
tasteful solutions involved adding new args to WRITE which indicated
the nature of the recursive use of the printer. Others objected that
nobody uses WRITE, so that isn't a real fix.
This was discussed about a month ago. Only God knows how many
unresolved issues lie buried and forgotten in the Common Lisp archive.
Rob
∂15-Dec-85 1855 JAR@MIT-MC.ARPA Another omission: global lexicals
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 18:55:41 PST
Date: Sun, 15 Dec 85 21:58:18 EST
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].755383.851215.JAR>
Date: Sun, 15 Dec 1985 14:53 EST
From: Rob MacLachlan <RAM at C.CS.CMU.EDU>
It is also worth noting that it should be trivial to add global
lexicals to any implementation. The value is kept in the global value
cell, just as for a special; the only difference is that there is no
special annotation.
I interpret your suggestion as saying that DEFGLOBAL means the same
thing as SETQ, except that it lets compilers know that you really do
want a global lexical variable, so they shouldn't generate warning
messages that they might otherwise be inclined to generate ("FOO
declared special"). If you dynamically bind one, everyone sees the
dynamic binding.
I agree that this would be nice. You have to make sure you know how
implementations which use deep binding for special variables are going
to deal with this; my interpretation of your proposal makes different
implementation demands from Weinreb's interpretation. However, I think
deep-bound Common Lisps can simply cause references to DEFGLOBAL'ed
variables to always go through its top-level value cell (presumably one
still exists, even if the variable has been dynamically bound).
SYMBOL-VALUE would still always get the special binding.
I think one could go either as you suggest or as Weinreb suggests on
this. My reading of your proposal seems to be a less radical departure
from common lisp. But it's important to keep in mind the distinction
and consider the ramifications and possible generalizations of any
proposal.
I'm also frustrated by the absence of global lexical variables. There's
no way you can PREVENT a LET or LAMBDA from doing dynamic binding if the
variable obtained its top-level binding with DEFVAR. To make matters
worse, some implementations (viz. the one I use) even discourage you
from doing top-level references and SETQ's on variables which haven't
been declared or proclaimed SPECIAL - you get "FOO declared special"
messages (fortunately it does a DECLARE and not a PROCLAIM!).
I asked the list a while ago if anyone could remember why there was no
UNSPECIAL declaration in the language, and I didn't get any answer. If
UNSPECIAL existed, you could redefine LET, LAMBDA, etc. to put implicit
DECLARE UNSPECIAL's in their bodies, and get the effect of global
lexicals just by using DEFVAR. The only reason I can think of to
exclude UNSPECIAL is to avoid putting constraints on deep-bound or
hybrid implementations.
The solution I ended up using is this: I use SETQ, never DEFVAR to
introduce a top-level binding; I always write
(locally (declare (special x)) x)
to reference the global "x" (to inhibit the compiler's automatic DECLARE
SPECIAL and its annoying warning message); I use
(let ((temp (compute-value ...)))
(setq x temp))
to make an assignment (for the same reasons - and macroized, of course);
and I never use implicit (proclaimed) SPECIAL declarations - if I want
to do a special binding I use a DECLARE.
Of course, my code will very likely stop working if I ever run it in a
deep-bound implementation.
In short: DEFGLOBAL is an important addition to the language, and very
easy to implement. (It will probably wreak havoc on the manual - how
many places implicitly assume that global variables are always special?)
-----
[Aside: MIT Scheme and T have a generalization of this which allows ANY
lexical variable to be dynamically bound. As in your proposal,
top-level lexicals and top-level specials live in the same place.
Specials are lexically shadowed by lexical bindings of the same name,
but any lexical variable, not just a top-level lexical variable, can be
dynamically bound. Dynamicness is not a property of variables (names),
but of binding.
I would expect people who haven't thought about this before to be
confused. I certainly was when I first saw it. Here is an example.
(setq y 'top)
(defun foo1 ()
(let ((y 'lexical))
(bar #'(lambda (f)
(fluid-let ((y 'fluid))
(funcall f))) ;scheme dynamic binding
#'(lambda () y))))
(defun foo2 ()
(let ((y 'lexical))
(bar #'(lambda (f)
(let ((y 'fluid))
(declare (special y)) ;CL dynamic binding, for comparison
(funcall f)))
#'(lambda () y))))
(defun bar (g h)
(funcall g #'(lambda () (list (funcall h) y))))
(foo1) => (FLUID TOP)
(foo2) => (LEXICAL FLUID) ;[probably, at least in shallow implementations]
The semantics of (fluid-let ((x value)) body) is similar to
(let ((temp x))
(setq x value)
(unwind-protect body
(setq x temp)))
except of course that it interacts properly with context switches. It
turns out this facility is moderately useful. And it works in either
shallow-bound implementations or deep-bound ones (both MIT Scheme and T
use shallow binding right now, but T is changing to deep binding).
I think this is subsumed by Zetalisp's LETF, for those of you familiar
with that.]
- Jonathan
∂15-Dec-85 1935 RAM@C.CS.CMU.EDU list of proposed changes to Common Lisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 19:35:09 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 22:34:59-EST
Date: Sun, 15 Dec 1985 22:34 EST
Message-ID: <RAM.12167452884.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: list of proposed changes to Common Lisp
(*) 158 Specify that it is an error for more than one TYPE declaration
for a given variable to appear in a group of declarations (those all
at the head of the same body), or more than one FTYPE or FUNCTION
declaration for a given function name, or both an INLINE and a
NOTINLINE declaration for the same function.
I think this is excessively restrictive. The obvious meaning of
multiple type declarations for the same variable is that the value of
the variable is of *both* types. (declare (type a foo) (type b foo))
is the same as (declare (type (and a b) foo)).
This feature could actually be used to good effect. Suppose a clever
writer of the DOTIMES macro realized that the variable will always be
of type (INTEGER 0), and added such a declaration in the expansion.
The user of DOTIMES might know that the upper bound is always a
fixnum, and write (dotimes (i x) (declare (fixnum i)). The compiler
could then determine that the step variable is in fact a non-negative
fixnum, which might be a useful piece of information.
Note that if the declared types are known to be disjoint, the variable
will have effectively been declared to be of type NIL, thus the
binding (not the declaration) is illegal, since its initial value
cannot be of type NIL. Note also that this interpretation won't break
anything; the variable belongs to all the types, thus an
implementation which uses any one will still be correct.
An FTYPE declaration is identical to a type declaration except for
specifying the result of functional evaluation, so the same reasoning
holds. A FUNCTION declaration is in fact a (TYPE FUNCTION ...)
declaration, so this is also reasonable.
I have no objection of saying that conflicting INLINE and NOTINLINE
declarations are illegal, but due to the advisory nature of INLINE
declarations, it might be reasonable to say the compiler can obey
whichever declaration it feels like.
While we are talking about types, I will mention that there is a
missing type specifier, namely REAL, which is probably the same as
(OR FLOAT RATIONAL). Although probably useless as a declaration, it
is useful for things like CHECK-TYPE.
Rob
∂15-Dec-85 2128 RAM@C.CS.CMU.EDU Another omission: global lexicals
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 21:26:35 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 16 Dec 85 00:26:15-EST
Date: Mon, 16 Dec 1985 00:26 EST
Message-ID: <RAM.12167473144.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals
In-reply-to: Msg of 15 Dec 1985 21:58-EST from Jonathan A Rees <JAR at MIT-MC.ARPA>
Each symbol potentially has one global value cell. This value cell is
used to store the value of global variables and constants. The
functions SYMBOL-VALUE, BOUNDP and MAKUNBOUND operate on this value
cell. References to global lexical variables and constants may use
this cell directly. In a shallow-binding Lisp, a special binding
shallow-binds this cell, and a special reference reads this cell.
In a deep-binding Lisp, some search needs to be done for a special
reference or store.
You are right. In fact I think it wouldn't break any Common Lisp
programs (certainly not any tasteful ones) to allow dynamic bindings
on any variable. It would only make a difference in contorted cases
where there is both a lexical binding and a special binding of the
same name in the same lexical scope. I doubt this exists outside of
the example in the manual.
If even this slight possibility scares you, then you could say
that a special binding always binds the global value cell for the symbol.
∂15-Dec-85 2134 RAM@C.CS.CMU.EDU Another omission: global lexicals
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 21:34:03 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 16 Dec 85 00:33:45-EST
Date: Mon, 16 Dec 1985 00:33 EST
Message-ID: <RAM.12167474504.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals
Now that I'm done editing, let's try again:
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Beautiful: I knew there was a justification for the obvious
implementation. A special binding is actually a binding of the global
value cell. Each symbol potentially has one global value cell. This
value cell is used to store the value of global variables and
constants. The functions SYMBOL-VALUE, BOUNDP and MAKUNBOUND operate
on this value cell. In a shallow-binding lisp, all global references
can go directly to this cell. In a deep-binding lisp, global
references other than special references can go direct; special
references potentially involve a search.
In fact I think it wouldn't break any Common Lisp programs
(certainly not any tasteful ones) to allow dynamic bindings on any
variable. It would only make a difference in contorted cases where
there is both a lexical binding and a special binding of the same name
in the same lexical scope. I doubt this exists outside of the example
in the manual.
Rob
∂16-Dec-85 0303 cfry%MIT-OZ@MIT-MC.ARPA clarifications
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 03:03:28 PST
Received: from MIT-JANIS by MIT-OZ via Chaosnet; 16 Dec 85 06:02-EST
Date: Mon, 16 Dec 85 06:03 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: clarifications
To: common-lisp@SU-AI.ARPA
Message-ID: <851216060351.3.CFRY@JANIS.AI.MIT.EDU>
130: Self-evaluating forms (such as strings] in tagbodies
are no-ops but otherwise harmless.
Its not worth it to make a special case to rule them out.
Code (or humans) that write/modify other code shouldn't have to worry
about what's in the body that its wrapping a tagbody around.
268: Can the proposed COPY be installed like SETF?
Call it COPYF. Depth of copying could be specified with
an integer.
425: Along with FILE-LENGTH, it would be nice to be
able to ask the operating system how much
disk-space is available in a given directory,
so you could have some control when attempting to
write too-large files without going through
some error mechanism.
(disk-free-space pathname) => number of bytes available.
∂16-Dec-85 0641 DLW@SCRC-STONY-BROOK.ARPA Another omission: global lexicals
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 06:41:15 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374896; Mon 16-Dec-85 09:40:13-EST
Date: Mon, 16 Dec 85 09:48 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, RAM@C.CS.CMU.EDU
In-Reply-To: <[MIT-MC.ARPA].755061.851215.GJC>
Message-ID: <851216094829.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sun, 15 Dec 85 18:05:36 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Seriously Dan, if you fellows go before the ISO and say that
"The oft-discussed:"
is vague with respect to legality in Common Lisp the USA is going to
look pretty wimpy.
You're right, George. I'll never again say that anything is vague with
respect to legality. Every issue is clear-cut. We'll see if we can get
Rambo for the technical committee.
∂16-Dec-85 0657 wagner%fang@gswd-vms &ALLOW-OTHER-KEYS
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 06:57:42 PST
Received: from fang.GSD (fang.ARPA) by gswd-vms.ARPA (5.9/5.6)
id AA08881; Mon, 16 Dec 85 08:58:46 CST
Message-Id: <8512161458.AA08881@gswd-vms.ARPA>
Date: Mon, 16 Dec 85 08:57:27 cst
From: wagner%fang@gswd-vms (Fran Wagner)
To: common-lisp@su-ai.arpa
Subject: &ALLOW-OTHER-KEYS
Cc: wagner%fang@gswd-vms
In the clarifications that Guy distributed in Boston, mention is
made of &ALLOW-OTHER-KEYWORDS (p.1). In CLtL and in implementations
I could check, this lambda-list keyword is named &ALLOW-OTHER-KEYS.
The KEYWORDS form is more natural, but it is a mistake, right?
--Fran
∂16-Dec-85 0704 DLW@SCRC-STONY-BROOK.ARPA Another omission: global lexicals
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 07:03:21 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374918; Mon 16-Dec-85 10:03:00-EST
Date: Mon, 16 Dec 85 10:11 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU
cc: JAR@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12167474504.BABYL@C.CS.CMU.EDU>
Message-ID: <851216101119.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
I thought we were in agreement, but now I'm not sure. What does this
program print?
(defglobal g 4)
(set 'g 5)
(defun foo ()
(setq g 6))
(foo)
(print g)
In my interpretation of your original proposal, (print g) is referring
to g lexically, since nobody ever declared it special. foo is referring
to g lexically also. The value of the symbol named g is irrelevant; the
program prints 6.
Before I continue this message, is it your current claim that it prints
6, or that it prints 5?
∂16-Dec-85 0935 gls@THINK-AQUINAS.ARPA list of proposed changes to Common Lisp
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 09:34:52 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 12:34:48 est
Date: Mon, 16 Dec 85 12:34 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: list of proposed changes to Common Lisp
To: RAM@C.CS.CMU.EDU, gls@THINK-AQUINAS.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <RAM.12166952525.BABYL@C.CS.CMU.EDU>
Message-Id: <851216123446.3.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Sat, 14 Dec 1985 00:46 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
(*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
not perform macro-expansion on the given form ...
This won't work, as it prohibits defining setf methods for macros.
GET-SETF-METHOD needs the environment so that it can expand macros one
level at a time, checking if the result has a setf method. I also
suggest that the environment argument not be optional, as any user
code which doesn't supply it is surely broken.
Right you are.
312 It should be explicitly noted somewhere that defstruct copiers
work on structures which are a subtype by inclusion, e.g. COPY-PERSON
works on an astronaut. This is a natural consequence of the subtype
semantics of inclusion, but isn't necessarily obvious to pea-brained
implementors.
Presumably COPY-PERSON, when applied to an ASTRONAUT, returns something
that is a PERSON but not an ASTRONAUT; that is, it makes a copy of just
the PERSON part of an ASTRONAUT?
--Guy
∂16-Dec-85 1002 gls@THINK-AQUINAS.ARPA Questions, comments and clarifications on clarifications
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:01:58 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:01:46 est
Date: Mon, 16 Dec 85 13:01 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: DLW@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851215163501.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851216130145.5.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Sun, 15 Dec 85 16:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
425: A new argument, :ELEMENT-TYPE, to FILE-LENGTH is proposed, but the
proposal doesn't say what it means. I'd like to hear what this argument
is supposed to be defined to mean, expressed in a way that is
implementation-independent in any sense, such that this argument could
ever be used in a portable program and relied upon to do any specific
thing in particular.
Sorry it wasn't clean. FILE-LENGTH is defined to return the length of a
file measured in units of ELEMENT-TYPE. FILE-LENGTH now is guaranteed
to work only on an open stream, and it uses the ELEMENT-TYPE specified
when the stream was opened. The proposal is to allow FILE-LENGTH to
take any pathname, but in that case it may be necessary to specify an
ELEMENT-TYPE explicitly in order to get the answer you want.
439: What is COMPILEDP defined to do if you give it a lexical closure
over a function that is compiled?
I would say it should return T.
443: Do you also want to say that APROPOS might find some specific
symbols more than once, assuming that 187 is accepted?
Yep.
∂16-Dec-85 1005 gls@THINK-AQUINAS.ARPA XOR
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:05:05 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:05:08 est
Date: Mon, 16 Dec 85 13:05 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: XOR
To: Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <851215163550.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Sun, 15 Dec 85 16:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
The XOR function in your list of suggested language improvements
handed out last week was intended to be a joke, wasn't it? I assumed
it was, but other people on the mailing list are taking it seriously,
so I'm asking for clarification.
Of all the functions not in Common Lisp that I use day-to-day on my
3600, this is the one I use most frequently. I admit that I have been,
among other things, constructing logic models of various kinds.
However, I also find it useful in random COND clauses. Maybe the rest
of you will decide it is not useful, but in any case it is not a joke.
∂16-Dec-85 1014 gls@THINK-AQUINAS.ARPA Another omission: global lexicals
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:14:16 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:14:09 est
Date: Mon, 16 Dec 85 13:14 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU, DLW@SCRC-QUABBIN.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <RAM.12167410294.BABYL@C.CS.CMU.EDU>
Message-Id: <851216131407.7.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Sun, 15 Dec 1985 18:40 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Yes, we seem to be talking about the same thing. I believe you
have the right model for interaction with specials: there is none.
Unfortunately this means that shallow-binding implementations would
have to have separate lexical and special value cells, since you could
do something like this:
(defglobal foo :global)
(let ((foo :special))
(declare (special foo))
(bar))
(defun bar ()
(format t "~S or ~S, take you pick."
foo (locally (declare (special foo)) foo)))
This doesn't mean that your symbol needs another slot though. You
could keep the lexical value cells somewhere else (such as on the
PLIST!!), since you only need to locate the value cell at load time.
Rob
I think it is a bad idea to let "global lexicals" and specials be completely
independent, for the simple reason that in
(defvar foo 3)
(defun baz () foo)
(baz) => 3
(defglobal foo 5)
(baz) => 5
the DEFGLOBAL changes the meaning of the variable reference in BAZ.
Right now the meaning of FOO within BAZ can be determined by inspection
of only BAZ: because there is no *lexically apparent* lexical binding,
the reference to FOO must be special. With DEFGLOBAL as proposed, the
meaning of FOO cannot be understood out of context.
Here is a different model for DEFGLOBAL: it is just like DEFCONSTANT
except you are allowed to SETQ it. So you can change its value with a
side effect (or even make it unbound), but it is an error to bind it.
--Guy
∂16-Dec-85 1032 gls@THINK-AQUINAS.ARPA meta corrections to CLtL
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:31:48 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:31:44 est
Date: Mon, 16 Dec 85 13:31 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: meta corrections to CLtL
To: cfry@OZ.AI.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851216055254.2.CFRY@JANIS.AI.MIT.EDU>
Message-Id: <851216133143.9.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Mon, 16 Dec 85 05:52 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
I updated my copy of CLtL to include all
of your comments, except that I think you made a few errors
in the Corrections doc:
189 fewethings => few things
Your habit of typing e where SPACE should be is pretty confusing!
I forgot to mention this at the conference: the handouts I produced were
printed on a laser printer that was placed a bit too far from its host
(on a long cable) or something. Some electrical glitch causes it to
randomly turn a space into "a" or "e". This seems to occur only when
the space immediately follows a "w".
--Guy
∂16-Dec-85 1035 gls@THINK-AQUINAS.ARPA &ALLOW-OTHER-KEYS
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:34:12 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:34:12 est
Date: Mon, 16 Dec 85 13:34 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: &ALLOW-OTHER-KEYS
To: wagner%fang@GSWD-VMS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8512161458.AA08881@gswd-vms.ARPA>
Message-Id: <851216133412.0.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Mon, 16 Dec 85 08:57:27 cst
From: wagner%fang@gswd-vms (Fran Wagner)
In the clarifications that Guy distributed in Boston, mention is
made of &ALLOW-OTHER-KEYWORDS (p.1). In CLtL and in implementations
I could check, this lambda-list keyword is named &ALLOW-OTHER-KEYS.
The KEYWORDS form is more natural, but it is a mistake, right?
--Fran
Yes, I made a mistake. Thanks for pointing it out.
--Guy
∂16-Dec-85 1058 DCP@SCRC-QUABBIN.ARPA get-setf-method
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 10:58:04 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228614; Mon 16-Dec-85 13:52:25-EST
Date: Mon, 16 Dec 85 13:58 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: get-setf-method
To: Common-Lisp@SU-AI.ARPA
Message-ID: <851216135850.0.DCP@NEPONSET.SCRC.Symbolics.COM>
Excuse me if this has already been cleared up, but
(get-setf-method (macroexpand form env))
just won't cut it. Consider this example:
(defmacro raster-aref (raster-array x y)
...code-to-ensure-order-of-evaluation...
`(aref ,raster-array ,y ,x))
(defsetf raster-aref ...)
Now,
(raster-aref array (foo) (bar))
expands into (in our system, at least)
(let ((.gensym-for-raster-array. array)
(.gensym-for-bar. (bar)))
(aref .gensym-for-raster-array. .gensym-for-bar. (foo)))
Since when does LET have a DEFSETF method?
I agree with whoever said the environment should be a required argument.
∂16-Dec-85 1058 DLW@SCRC-QUABBIN.ARPA Questions, comments and clarifications on clarifications
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 10:57:43 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228613; Mon 16-Dec-85 13:52:07-EST
Date: Mon, 16 Dec 85 14:05 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <851216130145.5.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 16 Dec 85 13:01 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Sorry it wasn't clean. FILE-LENGTH is defined to return the length of a
file measured in units of ELEMENT-TYPE. FILE-LENGTH now is guaranteed
to work only on an open stream, and it uses the ELEMENT-TYPE specified
when the stream was opened. The proposal is to allow FILE-LENGTH to
take any pathname, but in that case it may be necessary to specify an
ELEMENT-TYPE explicitly in order to get the answer you want.
If this is what you mean, it should be made clear that (1) the model of
a "file" is that it has a single associated element-type, and (2) if you
use the new form of file-length, and you pass in :element-type, then the
value must be the same as the actual element-type of the file, or else
it is an error (the result is undefined).
(Put more crudely, there should be no defined way to write a file in
units of X and then ask for its length in units of Y, that claims to be
portable.)
∂16-Dec-85 1149 DLW@SCRC-QUABBIN.ARPA Another omission: global lexicals
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 11:49:12 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228643; Mon 16-Dec-85 14:43:43-EST
Date: Mon, 16 Dec 85 14:57 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: gls@THINK-AQUINAS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851216131407.7.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851216145707.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 16 Dec 85 13:14 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
(defvar foo 3)
(defun baz () foo)
(baz) => 3
(defglobal foo 5)
(baz) => 5
the DEFGLOBAL changes the meaning of the variable reference in BAZ.
In the only semantics that currently seems to make sense to me, the
DEFGLOBAL does not change the meaning. Since FOO is still declared
special, the FOO in the body of BAZ is still a special reference.
Unless you are assuming that DEFGLOBAL does a sort of (PROCLAIM (UNSPECIAL)),
which I am not.
Right now the meaning of FOO within BAZ can be determined by inspection
of only BAZ: because there is no *lexically apparent* lexical binding,
the reference to FOO must be special. With DEFGLOBAL as proposed, the
meaning of FOO cannot be understood out of context.
I'm not sure I concur with this logic. The meaning of FOO within BAZ
depends on non-lexically-local information, namely whether FOO has been
proclaimed special. In present CL as I know it, FOO is either a special
reference or an error depending on whether FOO is proclaimed special; in
the new proposal, semantics as I am assuming, FOO is either a special
reference or a local reference or an error, depending on whether FOO is
proclaimed special and on whether FOO is part of the global lexical
environment or not. So the DEFGLOBAL is just another thing like a
special proclaimation.
Again, I'm not trying to support anything or object to anything, just
trying to nail down what it is that the proposal means.
∂16-Dec-85 1154 RAM@C.CS.CMU.EDU list of proposed changes to Common Lisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Dec 85 11:53:44 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 16 Dec 85 14:14:20-EST
Date: Mon, 16 Dec 1985 14:14 EST
Message-ID: <RAM.12167623892.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: list of proposed changes to Common Lisp
In-reply-to: Msg of 16 Dec 1985 12:34-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Date: Monday, 16 December 1985 12:34-EST
From: Guy Steele <gls at THINK-AQUINAS.ARPA>
Re: list of proposed changes to Common Lisp
Presumably COPY-PERSON, when applied to an ASTRONAUT, returns
something that is a PERSON but not an ASTRONAUT; that is, it makes a
copy of just the PERSON part of an ASTRONAUT?
Well, so maybe it's not so clear-cut. I thought the obvious
interpretation was that COPY-PERSON was the same thing as
COPY-ASTRONAUT when applied to an astronaut. It now seems we have
three possible interpretations:
1] It is illegal to use a copier for an included structure on an
instance of the including structure.
2] The copier for the included structure returns an object of the
same type as the included structure, containing only the included
slots.
3] The copier for the included structure also copies instances of any
structure which include it.
If there are three modedately reasonable interpretations, is even more
important to specify which applies. One thing worth considering is
how well the interpretation fits into possible object-oriented
programming systems such as Common Loops.
Rob
∂16-Dec-85 1400 masinter.pa@Xerox.ARPA Re: Special Form Question
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 14:00:20 PST
Received: from Salvador.ms by ArpaGateway.ms ; 16 DEC 85 13:04:11 PST
Date: 16 Dec 85 13:03 PST
From: masinter.pa@Xerox.ARPA
Subject: Re: Special Form Question
To: common-lisp@SU-AI.ARPA
Message-ID: <851216-130411-1214@Xerox>
It would be more consistent and portable to define
(symbol-function 'quote) => nil.
under the theory that "symbol-function" really means to return a
function rather than "what this symbol means when seen as car of
something to be EVAL'd."
Similarly, it would be more consistent and portable to require that
after (defmacro foo --) that (symbol-function 'foo) also return nil.
This would mean that values returned by symbol-function could be assumed
to be functions, in the "funcall-able" sense.
It is likely that implementations will want to have some internal
"really give me what this symbol means when you see it as the CAR of a
form about to be EVALd" for use by the interpreter, but its not clear to
me why that primitive has to be "symbol-function".
Larry
∂16-Dec-85 1412 GSB@MIT-MC.ARPA get-setf-method
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 14:12:39 PST
Date: Mon, 16 Dec 85 17:15:19 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
Subject: get-setf-method
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].756838.851216.GSB>
I had thought it had been established long ago that the environment
argument is necessary. Not only for the reason Dave Plummer notes,
but also for the correct macroexpansion of macros from within setf
methods (such as LDB). I have no objections to the environment argument
to get-setf-method being required, although I would be inclined to
make it optional just as it is to macro-expand. Although one could
argue for the environment arg to macro-expand being required, similarly...
∂16-Dec-85 1518 masinter.pa@Xerox.ARPA Re: clarifications
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 15:17:59 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 DEC 85 14:37:51 PST
Date: 16 Dec 85 14:37 PST
From: masinter.pa@Xerox.ARPA
Subject: Re: clarifications
In-reply-to: Christopher Fry <cfry@OZ.AI.MIT.EDU>'s message of Mon, 16
Dec 85 06:03 EST
To: cfry@OZ.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <851216-143751-1352@Xerox>
Some pathnames don't denote disks, and yet "free-space" is a meaningful
concept. Why not "free-space" or "file-free-space" at least, instead of
"disk-free-space"?
∂16-Dec-85 1524 DCP@SCRC-STONY-BROOK.ARPA XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 15:23:58 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375442; Mon 16-Dec-85 16:42:38-EST
Date: Mon, 16 Dec 85 16:44 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: XOR
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, Moon@SCRC-STONY-BROOK.ARPA,
Steele@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 16 Dec 85 13:05 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Sun, 15 Dec 85 16:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
The XOR function in your list of suggested language improvements
handed out last week was intended to be a joke, wasn't it? I assumed
it was, but other people on the mailing list are taking it seriously,
so I'm asking for clarification.
Of all the functions not in Common Lisp that I use day-to-day on my
3600, this is the one I use most frequently. I admit that I have been,
among other things, constructing logic models of various kinds.
However, I also find it useful in random COND clauses. Maybe the rest
of you will decide it is not useful, but in any case it is not a joke.
One argument I have heard against XOR is that, unlike AND and OR, it
must evaluate all of its forms.
Of course, MLB once sent an amusing thing describing an XOR that returns
the right answer but somehow knows what the forms evaluate to so it can
stop early after the things it doesn't know a priori !-}
∂16-Dec-85 1703 mips!escargot.earl@glacier Re: Special Form Question
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 17:01:39 PST
Received: by glacier with Sendmail; Mon, 16 Dec 85 17:00:25 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
id AA10372; Mon, 16 Dec 85 16:30:09 pst
Received: by escargot.UUCP (4.12/4.7)
id AA04100; Mon, 16 Dec 85 16:29:10 pst
Date: Mon, 16 Dec 85 16:29:10 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8512170029.AA04100@escargot.UUCP>
To: masinter.pa@Xerox.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: glacier!masinter.pa@Xerox.ARPA's message of 16 Dec 85 13:03 PST
Subject: Re: Special Form Question
Date: 16 Dec 85 13:03 PST
From: glacier!masinter.pa@Xerox.ARPA
It would be more consistent and portable to define
(symbol-function 'quote) => nil.
under the theory that "symbol-function" really means to return a
function rather than "what this symbol means when seen as car of
something to be EVAL'd."
Similarly, it would be more consistent and portable to require that
after (defmacro foo --) that (symbol-function 'foo) also return nil.
This would mean that values returned by symbol-function could be assumed
to be functions, in the "funcall-able" sense.
It is likely that implementations will want to have some internal
"really give me what this symbol means when you see it as the CAR of a
form about to be EVALd" for use by the interpreter, but its not clear to
me why that primitive has to be "symbol-function".
Alternatively, you could leave symbol-function as the thing that
accesses a symbol's "function cell", and provide a new function that
is the same as FUNCTION, except that its argument is evaluated. It
could be applied to things other than symbols (e.g. lists with CAR =
LAMBDA). Call it FEVAL?? Then you could eliminate lambda
expressions as functions (the only argument for them was that you
needed to be able to construct functions on the fly -- now you can
construct lambda expressions and use FEVAL to turn them into
functions).
∂16-Dec-85 2018 DLW@SCRC-STONY-BROOK.ARPA Non-top-level DEFUN
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 20:18:11 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375729; Mon 16-Dec-85 23:17:43-EST
Date: Mon, 16 Dec 85 23:18 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Non-top-level DEFUN
To: common-lisp@SU-AI.ARPA
Message-ID: <851216231823.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
In recent mail, I said that I wasn't sure that DEFUNs inside a top-level
LET were valid CL. This was a completely error on my part, resulting
from my having spent too much time in design discussions to remember how
they came out. Yes, it's legal Common Lisp. And the Symbolics
implementation supports it correctly, too. Sorry about that.
∂16-Dec-85 2042 FAHLMAN@C.CS.CMU.EDU Non-top-level DEFUN
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Dec 85 20:41:53 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 16 Dec 85 23:41:16-EST
Date: Mon, 16 Dec 1985 23:41 EST
Message-ID: <FAHLMAN.12167727095.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Non-top-level DEFUN
In-reply-to: Msg of 16 Dec 1985 23:18-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Whether or not Weinreb was confused, the larger point remains:
The notion of "top-level form" is a complete disaster and should be
abolished. We should flush this in favor of a careful specification of
just what things the compiler is required to handle in well-defined ways
and which things are left to the discretion of the implementor. We've
got enough experience by now that we can tie down some things that we
were afraid to specify earlier.
-- Scott
∂17-Dec-85 0808 gls@THINK-AQUINAS.ARPA Questions, comments and clarifications on clarifications
Received: from THINK.COM by SU-AI.ARPA with TCP; 17 Dec 85 07:59:50 PST
Received: from ignatius by GODOT.THINK.COM via CHAOS; Tue, 17 Dec 85 10:59:39 est
Date: Tue, 17 Dec 85 10:58 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: DLW@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851217105855.3.GLS@THINK-IGNATIUS.ARPA>
Date: Mon, 16 Dec 85 14:05 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Mon, 16 Dec 85 13:01 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
...
If this is what you mean, it should be made clear that (1) the model of
a "file" is that it has a single associated element-type, and (2) if you
use the new form of file-length, and you pass in :element-type, then the
value must be the same as the actual element-type of the file, or else
it is an error (the result is undefined).
(Put more crudely, there should be no defined way to write a file in
units of X and then ask for its length in units of Y, that claims to be
portable.)
I agree. I think that (1) was already, if not clear, then at least translucent
from the existing description of FILE-LENGTH. Clearly (2) is a necessary
consequence for portability.
∂17-Dec-85 0911 gls@THINK-AQUINAS.ARPA Questions, comments and clarifications on clarifications
Received: from THINK.COM by SU-AI.ARPA with TCP; 17 Dec 85 07:59:50 PST
Received: from ignatius by GODOT.THINK.COM via CHAOS; Tue, 17 Dec 85 10:59:39 est
Date: Tue, 17 Dec 85 10:58 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: DLW@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851217105855.3.GLS@THINK-IGNATIUS.ARPA>
Date: Mon, 16 Dec 85 14:05 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Mon, 16 Dec 85 13:01 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
...
If this is what you mean, it should be made clear that (1) the model of
a "file" is that it has a single associated element-type, and (2) if you
use the new form of file-length, and you pass in :element-type, then the
value must be the same as the actual element-type of the file, or else
it is an error (the result is undefined).
(Put more crudely, there should be no defined way to write a file in
units of X and then ask for its length in units of Y, that claims to be
portable.)
I agree. I think that (1) was already, if not clear, then at least translucent
from the existing description of FILE-LENGTH. Clearly (2) is a necessary
consequence for portability.
∂17-Dec-85 1026 vanroggen%bizet.decnet@hudson.dec.com more comments
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 17 Dec 85 10:23:32 PST
Date: 17 Dec 85 11:50:00 EST
From: "BIZET::VANROGGEN" <vanroggen%bizet.decnet@hudson.dec.com>
Subject: more comments
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: vanroggen
Reply-To: "BIZET::VANROGGEN" <vanroggen%bizet.decnet@hudson.dec.com>
Comments on clarifications/minor changes:
1 UNDO is too vague.
I suggest something like either
(UNPROCLAIM '(CONSTANT FOO)) or (PROCLAIM '(NOTCONSTANT FOO))
Same for SPECIAL. We'll need a PROCLAIM CONSTANT too.
But wait--what will it mean to make incompatible proclamations?
As is said in [clarification 56,58], redefining a constant is
an error. Then surely making a constant a variable ought to be
at least as dangerous.
This problem is more general than just wanting to be able to "undo"
a definition--we need to decide how to change definitions. For
example, if one first (PROCLAIM '(FTYPE (FUNCTION STRING INTEGER) FOO))
and then (DEFUN FOO (S I) (DECLARE (TYPE SEQUENCE S) (TYPE FIXNUM I))
...), is the DECLARE in error or does it supersede the proclamation,
or does it just shadow the proclamation for the body of the function?
What if later (DEFUN FOO (A B C) (DECLARE (FLOAT A B C)) ...)?
Or if there's a PROCLAIM to that effect?
I hope we can define some reasonable behavior, but I think there will
always be some conflict between "static" proclamations and the "dynamic"
redefinitions done during program development until some notion of
"state" is introduced.
Also, should DEFVAR update the documentation string even when
the variable already had a value and thus didn't get reset?
47 The problem with the idiosyncratic use of &REST in a function type
specifier is that we really need a more general list-type description
without resorting to arbitrary predicates. Although &REST (INTEGER 0)
is a cute idea, I'm mildly opposed.
60 Yes, "an error" to have two parameters be the same symbol. I assume
"same (EQL) name" isn't really meant here, since the following should
be OK: (DEFUN FOO (PACK1:X PACK2:X) ...)
82 XOR seems to be stretching the analogy between control constructs and
logical operations a bit. BTW, there ought to be a mention of EVERY and
SOME in the descriptions of AND and OR if one wants to apply their
functionalities.
107,144 Would life, the language, and everything be simpler if MACROLET
didn't exist?
145 I'd prefer (BODY &OPTIONAL DOCP ENV) for PARSE-BODY where DOCP
defaults to NIL.
145 Is it OK to destroy the non-top-level list provided by &REST? Should
this be different for macros than for functions?
158 No, this should be an error only if the types conflict.
161 Should be OK if there are fewer returned values if they still match
the type specified. (I.e., if NIL is TYPEP the given type).
249 Hmmm. For now we can state that circular lists are "an error", just
so the language can be more precisely defined.
307 Also watch out for a slot named "P".
321 EVAL doesn't need an environment arg--what's wrong with the existing
EVALHOOK function?
439 I didn't mean that COMPILE had to save the interpreted definition for
COMPILEDP to potentially return. Rather, +if+ COMPILE had saved it,
COMPILEDP would return it and UNCOMPILE would restore it. Also, COMPILEDP
is supposed to work on names and can be true for macros (and special
forms, though that's not relevant), which distinguishes it from
COMPILED-FUNCTION-P. COMPILEDP should be false for a closure over a
compiled function, but COMPILED-FUNCTION-P should be true.
---Walter
------
∂17-Dec-85 1129 edsel!jonl@su-navajo.arpa Functions for special operators
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 11:29:09 PST
Received: by su-navajo.arpa with Sendmail; Tue, 17 Dec 85 11:26:10 pst
Received: by edsel.uucp (2.2/SMI-2.0)
id AA04609; Tue, 17 Dec 85 10:51:50 pst
Date: Tue, 17 Dec 85 10:51:50 pst
From: edsel!jonl@su-navajo.arpa (Jon L White)
Message-Id: <8512171851.AA04609@edsel.uucp>
To: navajo!common-lisp@su-ai
Subject: Functions for special operators
[Following what appeared to be the majority opinion of some time ago, I'm
refering to "special forms" as "special operators"]
It's certainly consistent with the rest of Common Lisp for symbol-function
of a special operator to be "is an error" -- early versions of VAX/NIL put
a "trap" function there, with the interpreter dispatching through a table
which was completely independent of the symbol's function cell. Putting
any old random value [like, NIL] in the symbol-function cell would be also
be consistent.
But this does beg a question of implementation technology. Background on
this "question" is the following assertion, rooted in antiquity:
''The only "special operators" needed by Lisp are Lambda and Quote''
[sure, the lambda calculus reduced it to only one -- lambda -- but before
extending the discussion on this point, try to remember that Lisp isn't
exactly the lambda calculus]. For example, COND could be implemented as
a macro
(defmacro COND (&rest clauses)
`(COND-SUBR (QUOTE ,clauses)))
and then COND-SUBR would be written in the typical way that parts of an
interpreter are written. So it may appear that putting the code for
COND-SUBR directly into the symbol-function cell of COND is perfectly fine,
and maybe even a good way to distribute the code of the interpreter. After
all, it is only *how* the interpreter goes about fetching an argument for
COND that is somewhat odd; after the fetch has been completed, it doesn't
matter whether it dispatches through the symbol-function cell of COND, or
to another function obtained in another manner.
The three implementation technologies I've seen over the years are:
1) essentially nothing in the symbol-function cell of special operators;
the interpreter "discerns" and dispatches all special operators through
some other mechanism such as the table mentioned above; the compiler
also has a lot of special cases in it for them. Although this may be
closer to the spirit of CLtL, section 5.1.3, it is less commonly used.
2) extend the set of applicable, function-like objects to include FSUBRs
and MSUBRs; the former, when found in a symbol's function cell, makes
it a special operator, and the latter, when found in a symbol's function
cell, makes it a macro. The beauty of this approach is that it
disconnects the macro/special-operator question from any property of
the particular symbol which holds it; this is generally good since it
supports renaming easily, but it really isn't feasible for a Common Lisp
implementation -- as page 57 of CLtL says "... the predicates
'macro-function' and 'special-form-p' may both be true of the same
symbol". Nevertheless, it has been used in other Lisp implementations.
3) a variant of (2) -- only true functions are put into the symbol-function
cell, but some other property of the symbol [like, a bit in a "header"
word?] determines whether the meaning of that function is FSUBR of MSUBR.
There seems to be some good advantage to upgrading the macro-function idea
into an MSUBR, for it would simplify code which moves definitions around.
The mark against upgrading special operators into FSUBRs, however, is the
explicit desire of CLtL *not* to facilitate "moving special operators around"
except where there is also a macro definition (which would, of course, occupy
the symbol-function cell).
-- JonL --
P.S. Nit-picking addenda:
(i) "symbol-function cell" merely means a certain data abstraction, and
doesn't constrain the implementational technology.
(ii) the above macro definition for COND won't really work -- it would
at least have to have an &environment argument -- but it is only
a simplification for purposes of illustration.
∂17-Dec-85 1129 edsel!jonl@su-navajo.arpa "lexical" globals?
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 11:29:02 PST
Received: by su-navajo.arpa with Sendmail; Tue, 17 Dec 85 11:26:01 pst
Received: by edsel.uucp (2.2/SMI-2.0)
id AA04592; Tue, 17 Dec 85 10:50:24 pst
Date: Tue, 17 Dec 85 10:50:24 pst
From: edsel!jonl@su-navajo.arpa (Jon L White)
Message-Id: <8512171850.AA04592@edsel.uucp>
To: navajo!ram@c.cs.cmu.edu
Cc: navajo!common-lisp@su-ai
Subject: "lexical" globals?
Distinguishing dynamic variables from truly global variables came up at
Lucid last spring, and I think (but am not fully sure) that what you
are calling "lexical globals" is subsumed by the general issue of having
a GLOBAL declaration/proclamation. I've appended to the end of this note
the paper I circulated back then to a couple dozen people. Since it wasn't
a pressing issue, we didn't raise it in the mailing list, although I spoke,
verbally, at length with a few more people about the problem [in particular,
GLS, since I had imagined that ThinkCo would be interested in deep-bound
implementations of Common Lisp].
The reason that I'm not 100% sure that simple global variables cover what
you are calling "lexical globals" is the volume of discussion about
(let ((a <some-value>))
(defun foo ...)
(defun bar ...))
In this example, it's entirely possible that a "global" value cell for "a"
will be allocated, which is essentially different from the top-level global
value for "a". Something like this is possible with "block compilation" in
Interlisp -- the BLOCK declaration disconnects most of the names appearing
therein from the outside world, and the compiled image doesn't even have to
have symbols existing with those names (because the code is compiled in a
fashion similar to the more vanilla, strongly-typed languages,in which "global
variables" are just names for specific runtime memory cells).
Also, some comments in the recent discussion seem to be misleading as to
how a deep-bound implementation works; there is no "re-binding" of the
toplevel global value cell, but rather a stackframe which binds a special
variable will have a value cell right in that frame (and will also have the
name of the variable in the frame, at least implicitly if not directly
present in the frame). I'm not sure if there is a good reference on deep
binding in general -- the "spaghetti stack" papers are one source -- but
several implementations which I've seen have independently invented similar
sorts of "wheels" for accelerating performance. [Or, at least they did so
after a year's experience using the "oval wheels" they started out with!]
Perhaps you, and/or the other people who have volunteered opinions on this
topic, can comment on whether a GLOBAL declaration, in parallel to the SPECIAL
declaration, would be satisfactory; or whether there is a need for a more
scheme-like mechanism also.
-- JonL --
---------------------------------------------------------------------------
A "white paper" from March 1985
---------------------------------------------------------------------------
A serious shortfall exists in the defined capabilities for treating
variables either as global or as dynamic, which will badly impact the user
trying to write sensible code runnable both in a deep bound implementation
and in a shallow bound one. Common Lisp has gone on record as not being
limited to shallow-bound implementations, and with the appearance of
multi-processor work-stations and "computers", the issue of a deep-bound
implementation of CL is coming to reality.
This note is rather long, so I've organized the remainder into
four sections, with the the more important items first.
** Statement of the Problem
** Comparisons with Deep- and Shallow-Bound Interlisps
** A Noticeable Semantic Distinction
** Benefits of Distinction
Statement of the Problem
In Commonlisp Lisp, there is no means to specify that a variable's
references are "global" rather than dynamic [of course, this only applies
to free variable references -- global variables may not be bound].
Section 5.3.2 of the CL manual recommends 'defvar' as the means to declare
a variable as special, and (unwisely, I think) suggests this as the means of
defining "globally defined variables"; defconstant adddresses an issue not
really related to "variables", but rather to named constants (i.e., you cannot
setq a symbol which has been defined by defconstant); defparameter isn't
quite right either, depending on one's implementation (most implementations
I've seen cause defparamater to do a SPECIAL proclaimation on the variable).
Comparisons with Deep- and Shallow-Bound Interlisps
Interlisp-10 is a shallow-bound implementation, whereas Interlisp-D and
Interlisp/VAX are deep bound; so this problem of distinction has already been
faced in that world. Since the shortfall is hardly perceptible to the user
of a shallow-bound implementation, I recommend reading that part of the
Interlisp reference manual dealing with the differences between the functions
GETTOPVAL, GETATOMVAL, and EVALV. [This is found in section 2.4.1 of the
Oct 1983 version of the IRM, and at the end of section 5.1 of the Oct 1978
version]. The comments therein about performance implications are not just
theoretical, but have been observed to account for an order-of-magnitude
difference between a poorly ported application and a properly ported one.
Interlisp's EVALV corresponds by definition to CL's 'symbol-value'
[note well: symbol-value is *not* defined by reference to a "value cell",
but rather to the dynamic binding environment]; but there is no CL equivalent
to GETTOPVAL, and GETATOMVAL.
A Proffered Solution
Actually, defvar "proclaims" a variable to be special; to meet the
problems of this shortfall, there would need to be a declaration of globality
for variables, just as there is a declaration of dynamic scoping for them (see
the "special" section of section 9.2 in the manual). The observable
differences between a variable of global scope and one of dynamic, or special,
scope are:
(1) it is an error to bind a global variable, but setq'ing is ok; and
(2) a deep-bound implementation would do a "shallow" value-cell fetch
for global references, rather than the kind of free-variable lookup
it must do for dynamic references.
Additionally, there should be a 'defglobalvar' which proclaims a variable to
be of global scope, just as defvar proclaims one to be of dynamic scope.
A Noticeable Semantic Distinction
In addition to the perceived performance loss (in the deep-bound case)
of not making accurate global declarations, there is in fact a semantic
difference discernible in both deep and shallow.
(setq x "Topval for x")
(defun lookat ()
(let ((x "Random dynamic val for x"))
(declare (special x))
(list (see-special) (see-global))))
(defun see-special () (declare (special x)) x)
(defun see-global () (declare (global x)) x)
When the global declaration is correctly done, the result of (lookat) will
be ("Random dynamic val for x" "Topval for x") rather than
("Random dynamic val for x" "Random dynamic val for x")
[Let me forstall any side-tracking discussion about the inadvisibility of
using a variable both globally and specially in the same module. This example
is only for illustrative purposes; the issue is really the protection of
one module's usages against those of others, just as a local variable in one
function needs to be sheilded from the dynamic bindings in another, lexically
different, function.]
Benefits of Distinction
For the record, I will say that I believe programmers have in general
overused dynamic variables in the past, ** particularly when attempting to
define global state variables -- I've seen a lot of code that mistakenly
defines some global variable, which in fact holds something that is process
dependent, or application dependent. I think this will change in the future,
due to the influence of Scheme and to the insistence by this community for
correct lexical scoping in Lisp interpreters. This statement is only a
generalization, but it comes from observing much code that had to be re-thought
very carefully in the face of a multi-processing Lisp. One must distinguish
global state in a machine,
such as *modules* (section 11.8 of CL manual),
or, say, *network-routing-table*
from dynamic state
such as *package* or *read-base*
or, say, *standard-output* (which will be process-specific, at least)
Properly used, each has their own place, that will become more individually
secure as deep-bound implementations of CL come into being.
-- JonL --
∂17-Dec-85 1633 KMP@SCRC-STONY-BROOK.ARPA XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 16:32:45 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375936; Tue 17-Dec-85 10:44:57-EST
Date: Tue, 17 Dec 85 10:45 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA,
Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 16 Dec 85 16:44 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: XOR
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, Moon@SCRC-STONY-BROOK.ARPA,
Steele@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 16 Dec 85 13:05 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Sun, 15 Dec 85 16:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
The XOR function in your list of suggested language improvements
handed out last week was intended to be a joke, wasn't it? I assumed
it was, but other people on the mailing list are taking it seriously,
so I'm asking for clarification.
Of all the functions not in Common Lisp that I use day-to-day on my
3600, this is the one I use most frequently. I admit that I have been,
among other things, constructing logic models of various kinds.
However, I also find it useful in random COND clauses. Maybe the rest
of you will decide it is not useful, but in any case it is not a joke.
One argument I have heard against XOR is that, unlike AND and OR, it
must evaluate all of its forms.
Actually, that doesn't bother me. All three share the property that they evaluate
forms left to right until they have enough information to decide. The fact that
"enough information" is available early for AND and OR shouldn't be held against
XOR, which has other great properties to offer in exchange.
Of course, MLB once sent an amusing thing describing an XOR that returns
the right answer but somehow knows what the forms evaluate to so it can
stop early after the things it doesn't know a priori !-}
(:- Sure. eg, (WITHOUT-INTERRUPTS (XOR (FOO) (NOT (CAR X)) (CAR X))) :-)
On the more serious side, if we did introduce XOR, people might eventually
want reasonable answers to the following related issues, which would be left
open...
* Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)
* Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV,
ORC1, ANDC2, ... which do the other logical operations. If there were,
such forms (whatever they were named), some would have very peculiar
rules about when evaluation could be allowed to stop, and I'm not sure
if I'd want to have to learn them.
Certainly I've had a lot more use for NAND and NOR than for XOR.
A possibly reasonable alternative proposal might be to introduce a full set of
functional (ie, not special form) versions of all these operators. That way, we'd
simulataneously solve the problem that AND and OR cannot be applied (by providing
functions that could be). eg, just as a straw man I'll propose *AND, *IOR, *XOR,
*CLR, *SET, *EQV, *ORC1, ... Such functions could be known the the compiler and
interestingly optimized in predicate positions without needing to be special forms.
Also, (MAPCAR #'*AND (FOO)) or (APPLY #'*XOR (BAR)) would be possible.
∂17-Dec-85 2126 KMP@SCRC-STONY-BROOK.ARPA XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 16:32:45 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375936; Tue 17-Dec-85 10:44:57-EST
Date: Tue, 17 Dec 85 10:45 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA,
Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 16 Dec 85 16:44 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: XOR
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, Moon@SCRC-STONY-BROOK.ARPA,
Steele@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 16 Dec 85 13:05 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Sun, 15 Dec 85 16:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
The XOR function in your list of suggested language improvements
handed out last week was intended to be a joke, wasn't it? I assumed
it was, but other people on the mailing list are taking it seriously,
so I'm asking for clarification.
Of all the functions not in Common Lisp that I use day-to-day on my
3600, this is the one I use most frequently. I admit that I have been,
among other things, constructing logic models of various kinds.
However, I also find it useful in random COND clauses. Maybe the rest
of you will decide it is not useful, but in any case it is not a joke.
One argument I have heard against XOR is that, unlike AND and OR, it
must evaluate all of its forms.
Actually, that doesn't bother me. All three share the property that they evaluate
forms left to right until they have enough information to decide. The fact that
"enough information" is available early for AND and OR shouldn't be held against
XOR, which has other great properties to offer in exchange.
Of course, MLB once sent an amusing thing describing an XOR that returns
the right answer but somehow knows what the forms evaluate to so it can
stop early after the things it doesn't know a priori !-}
(:- Sure. eg, (WITHOUT-INTERRUPTS (XOR (FOO) (NOT (CAR X)) (CAR X))) :-)
On the more serious side, if we did introduce XOR, people might eventually
want reasonable answers to the following related issues, which would be left
open...
* Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)
* Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV,
ORC1, ANDC2, ... which do the other logical operations. If there were,
such forms (whatever they were named), some would have very peculiar
rules about when evaluation could be allowed to stop, and I'm not sure
if I'd want to have to learn them.
Certainly I've had a lot more use for NAND and NOR than for XOR.
A possibly reasonable alternative proposal might be to introduce a full set of
functional (ie, not special form) versions of all these operators. That way, we'd
simulataneously solve the problem that AND and OR cannot be applied (by providing
functions that could be). eg, just as a straw man I'll propose *AND, *IOR, *XOR,
*CLR, *SET, *EQV, *ORC1, ... Such functions could be known the the compiler and
interestingly optimized in predicate positions without needing to be special forms.
Also, (MAPCAR #'*AND (FOO)) or (APPLY #'*XOR (BAR)) would be possible.
∂17-Dec-85 2157 JAR@MIT-MC.ARPA "lexical" globals?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:38:24 PST
Date: Tue, 17 Dec 85 23:47:46 EST
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject: "lexical" globals?
To: edsel!jonl@SU-NAVAJO.ARPA
cc: common-lisp@SU-AI.ARPA, ram@C.CS.CMU.EDU
In-reply-to: Msg of Tue 17 Dec 85 10:50:24 pst from edsel!jonl at su-navajo.arpa (Jon L White)
Message-ID: <[MIT-MC.ARPA].758912.851217.JAR>
Date: Tue, 17 Dec 85 10:50:24 pst
From: edsel!jonl at su-navajo.arpa (Jon L White)
Perhaps you, and/or the other people who have volunteered opinions on this
topic, can comment on whether a GLOBAL declaration, in parallel to the SPECIAL
declaration, would be satisfactory; or whether there is a need for a more
scheme-like mechanism also.
I liked your message. I think that a (PROCLAIM '(GLOBAL FOO))
proclamation would do the trick. A DEFGLOBAL macro analogous to DEFVAR
would be convenient, and symmetrical with DEFVAR and the other DEF's.
Much as I like the feature, I think that adding the full generality of
the MIT/Yale Schemes' fluid-let would confuse too many people and anger
too many implementors. I only mentioned it for its educational value.
As far as forbidding LAMBDA-binding of globals, this hadn't occurred to
me, but it's probably the right thing, for similar reasons. Again, I'm
a fan of block structured languages, but Common Lisp simply is NOT block
structured, and this feature would be too confusing. Forbidding
lambda-binding globals sort of defeats the idea of lexical scoping, but
then so does (PROCLAIM '(SPECIAL ...)). Also, it's a conservative
approach, since it doesn't preclude possible later relaxation of the
language.
If Common Lisp hadn't re-cycled LAMBDA for the two different purposes of
lexical and dynamic binding, we wouldn't be having these problems now.
But c'est la vie. I can't really complain, since I didn't make a stink
about it when the decisions were being made. Maybe we'll get it right
next time around.
∂17-Dec-85 2213 mcvax!delphi.UUCP!beppe@seismo.CSS.GOV mailing list
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 17 Dec 85 21:41:18 PST
Return-Path: <mcvax!delphi.UUCP!beppe>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Wed, 18 Dec 85 00:37:39 EST
From: mcvax!delphi.UUCP!beppe@seismo.CSS.GOV
Received: by mcvax.UUCP; Wed, 18 Dec 85 05:56:13 +0100 (MET)
Received: by mcvax.UUCP; Wed, 18 Dec 85 05:56:03 +0100 (MET)
Received: by delphi.uucp (2.0/SMI-2.0)
id AA20558; Tue, 17 Dec 85 16:50:45 -0100
Date: Tue, 17 Dec 85 16:49:05 MET
Subject: mailing list
To: common-lisp@su-ai.arpa
Message-Id: <85/12/17 1649.144@delphi>
Could you please add my name to the Common Lisp mailing list?
Thank you.
Giuseppe Attardi
∂18-Dec-85 0330 cfry%MIT-OZ@MIT-MC.ARPA Re: clarifications
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 03:30:41 PST
Received: from MIT-JANIS by MIT-OZ via Chaosnet; 18 Dec 85 06:30-EST
Date: Wed, 18 Dec 85 06:30 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Re: clarifications
To: masinter.pa@XEROX.ARPA, cfry@OZ.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851216-143751-1352@Xerox>
Message-ID: <851218063059.1.CFRY@JANIS.AI.MIT.EDU>
Some pathnames don't denote disks, and yet "free-space" is a meaningful
concept. Why not "free-space" or "file-free-space" at least, instead of
"disk-free-space"?
Yes. You've helped clarify the intended semantics which is,
If I saved a file with pathname P, how big could it be before
it ran out of room?
"free-space" could mean: how much virtual memory have I got left?
"file-free-space" disambiguates, however, we might want to disambiguate
based on the type of the argument [with maybe a few keywords].
There could be a whole set of free-space functions for:
virtual-memory [ROOM prints out a user useful answer, not a number that
could be used by a program]
arrays [returns number of elements between fill pointer and the
real length]
numbers of various kinds [how much more they can grow before they reach
their limit. If number is negative, how much more they
can grow downward? This should probably be disambiguated with
a keyword. One problem is, you'd like to return a number of the
same type, which would be impossible to do for, say, a number
that was negative, to represent the distance to its positive max.]
hash-table [how much room before a rehash is necessary. This is necessarily
implementation dependent
Also, if there is a maximum size for a hash-table, how much
room until then?]
package how many more symbols can I stick in this package
readtable how many dispatch macros are undefined for the dispatch char
C, which would default to # .
stream You might want to open a stream for writting and specify a
limit. Free-space would tell you how far until that limit.
list
sequence
For lists and sequences, you might be adding to them sequentially, after having
initially creted them with some "empty" value such as NIL.
free-space could find out how much space there was from the end
until the first "non-empty" element. The empty value would default to nil.
Think of free-space like we've been thinking of undo, copy, setf ....
a generally useful concept that can be reasonably applied to a lot
of different data types.
It would make it easier to implement this free-space in terms of
another class of fns, SIZE or LENGTH.
There is already an attempt to make LENGTH work generically
in sequences. Why not with files, etc?
In fact, a bunch of the sequence operators could be meaningfully
applied to other data types.
I recognize that these concepts mesh
with ideas from new flavors and commonloops.
∂18-Dec-85 0701 preece%ccvaxa@gswd-vms Re: XOR
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 07:01:42 PST
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/5.6)
id AA00787; Wed, 18 Dec 85 09:02:27 CST
Message-Id: <8512181502.AA00787@gswd-vms.ARPA>
Date: Wed, 18 Dec 85 09:02:19 cst
From: preece%ccvaxa@gswd-vms (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: XOR
/**** ccvaxa:commonlisp / KMP@SCRC-STON / 11:42 pm Dec 17, 1985 ****/
From @SU-AI.ARPA:KMP@SCRC-STONY-BROOK.ARPA Tue Dec 17 23:41:59 1985
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: XOR
Steele@THINK-AQUINAS.ARPA
In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
...
On the more serious side, if we did introduce XOR, people might eventually
want reasonable answers to the following related issues, which would be left
open...
* Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)
----------
Actually, I don't like calling GLS's proposed function XOR. An
exclusive or should be true if exactly one of the arguments is
true, not if any odd number of arguments is true. The proposed
XOR isn't exclusive enough ...
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂18-Dec-85 0842 @MC.LCS.MIT.EDU:RAMBO@AI.AI.MIT.EDU recent request for assistance
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 08:38:23 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 DEC 85 11:40:47 EST
Date: Wed, 18 Dec 85 11:39:11 EST
From: RAMBO%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
Subject: recent request for assistance
To: dlw@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].8969.851218.RAMBO>
We learned of this through our usual sources inside the DIA. I
am at your disposal if the need arises. For all the overworked
implementors on this mailing list, may I suggest the relaxation of
my winter insurgency training camp.
∂18-Dec-85 1153 Gregor.pa@Xerox.ARPA what do :copiers do?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 11:53:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 DEC 85 11:23:17 PST
Date: 18 Dec 85 11:23 PST
From: Gregor.pa@Xerox.ARPA
Subject: what do :copiers do?
To: common-lisp@SU-AI.ARPA
Message-ID: <851218-112317-1434@Xerox>
Assuming that the functionality of being able to copy a structure and
get back a structure of the same type and the functionality of being
able to copy a particular "sub-type part" of a structure are worthwhile,
here is a scheme which seems nice:
Remember that:
(defstruct person name)
(defstruct (astronaut (:include person)) helmet-size)
In the scheme I am proposing:
- copy-person of an astronaut returns a person
- a "new" function, copy, which given an astronaut returns an astronaut
More abstractly,
COPY-xxx as defined by a defstruct returns a structure of that
defstruct's type.
COPY returns a structure of the same type as its argument.
∂19-Dec-85 0932 gls@THINK-AQUINAS.ARPA XOR
Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Dec 85 09:32:49 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 19 Dec 85 12:32:45 est
Date: Thu, 19 Dec 85 12:32 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: XOR
To: KMP@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA,
Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <851219123258.6.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Tue, 17 Dec 85 10:45 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
* Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)
I dunno. That goes way back into history.
* Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV,
ORC1, ANDC2, ... which do the other logical operations. If there were,
such forms (whatever they were named), some would have very peculiar
rules about when evaluation could be allowed to stop, and I'm not sure
if I'd want to have to learn them.
One problem is that NAND and NOR are not associative. They could reasonably
be restricted to being two-place. So could XOR, for that matter.
∂19-Dec-85 0935 gls@THINK-AQUINAS.ARPA READ-DELIMTED-LIST and dots
Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Dec 85 09:35:09 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 19 Dec 85 12:35:08 est
Date: Thu, 19 Dec 85 12:35 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: READ-DELIMTED-LIST and dots
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851219123523.7.GLS@THINK-JEHOSEPHAT.ARPA>
I propose that READ-DELIMITED-LIST be extended by adding one
more optional argument, dot-permitted-p, defaulting to nil,
that if true allows the delimited list to contain dot notation,
and if false forbids dot notation.
Right now the manual does not address the question of dot notation
in this context, and at least one implementation does not
permit dot notation in delimited lists, which makes that function
useless for simulating the action of "(".
∂19-Dec-85 1346 Masinter.pa@Xerox.ARPA fonts in CLtL
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 13:46:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 DEC 85 13:46:28 PST
Date: 19 Dec 85 13:09 PST
From: Masinter.pa@Xerox.ARPA
Subject: fonts in CLtL
To: common-Lisp@su-ai.ARPA
Message-ID: <851219-134629-1475@Xerox>
Are there any implementations which use a value of CHAR-FONT-LIMIT other
than 1, or a non-vacuous definition for CHAR-FONT? If not, could we
remove this feature from the language? (Under the theory that "optional"
features which no implementation uses should be removed from the
specification.)
----- Begin Forwarded Messages -----
Return-Path: <Moon@SCRC-STONY-BROOK.ARPA>
Received: from SCRC-STONY-BROOK.ARPA by Xerox.ARPA ; 17 DEC 85 18:18:31
PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via
CHAOS with CHAOS-MAIL id 376532; Tue 17-Dec-85 20:48:14-EST
Date: Tue, 17 Dec 85 20:43 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: fonts in CLtL
To: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>, masinter.pa
cc: rpg@SU-AI.ARPA, sybalsky.pa
In-Reply-To: <851216230521.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851217204330.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 16 Dec 85 23:05 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: 16 Dec 85 15:11 PST
From: masinter.pa@Xerox.ARPA
It was my impression looking over the latest Symbolics documentation
that Symbolics has moved away from using font-bits in characters. We've
found them impossible -- they don't contain enough information. If
there
aren't any other implementations that use font-bits, maybe we could get
rid of them.
I thought I'd ask privately before broadcasting.
Yes, I proposed this recently and I think that we have agreed to do
it.
Our model of character styles does not include any mapping from
integers
to styles (fonts) that is suitable for Common Lisp's model of the
font
attribute. (There is a mapping, but its lifetime is only over one
Lisp
environment, so it would be meaningless to say #3\A in a file.)
(I've CC'ed Moon so he can correct me if necessary.)
The above is all correct. CHAR-FONT-LIMIT will be 1 in our next
release, CHAR-FONT will always return 0, and we will have a field in
characters, whose value is an instance rather than an integer, that
doesn't pretend to be any of the Common Lisp character fields.
NB: None of this has anything to do with CHAR-BITS, which we make good
use of.
----- End Forwarded Messages -----
∂19-Dec-85 2051 apollo!dfm@uw-beaver.arpa GLS's clarifications list (moderately long)
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 19 Dec 85 20:51:39 PST
Received: by uw-beaver.arpa (4.42/4.2)
id AA03243; Thu, 19 Dec 85 20:53:17 PST
Return-Path: <apollo!dfm@uw-beaver.arpa>
Message-Id: <8512200453.AA03243@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Thu, 19 Dec 85 17:18:36 EST
Subject: GLS's clarifications list (moderately long)
To: COMMON-LISP@su-ai.arpa
Apologies if any of the following have been discussed and resolved before.
+ COMMON LISP's #n=/#n# syntax invites the creation of circular lists. For
example, the following seems more tasteful than the example with star, and
is, I believe, fairly perspicuous:
(mapcar #'cons p-list '#0=(property value . #0#))
Another place where circular lists are useful is with progv. Suppose I'm
passed a list of dynamic variables to be bound and initialized to nil, but
whose length I don't know. Three obvious ways are (1) to cons up a list
of nils at runtime, (2) write a recursive macro, and (3), the following, which
seems clearest:
(progv var-list '#0=(nil . #0#)
...)
Whether circular arguments to such functions are allowed or forbidden, all
the functions where folks might be tempted to use them may need to be identified,
so an explicit "it is an error to pass a circular list ...," "implementations
are required to support circular lists ...," or whatever can be put in their
descriptions. Alternatively some general rule, or possibly a table, can be
constructed. Since people can do some pretty tasteless things, the list
of possibilities is quite large. So far I've come up with the following,
although I'm sure I've missed some:
- map, every, some, notany, and notevery
- mapc, mapcan, mapcar, mapcon, mapl, and maplist
- the format directives ~?, ~{, ~:{, and ~:@{
- progv
- dolist
- the following, so long as :end (or possibly :end1, :end2, or :count) is
supplied, although for most of them I have a lot of trouble imagining why
anyone would actually try to use a circular list:
count, count-if, count-if-not, delete, delete-if, delete-if-not,
fill, find, find-if, find-if-not, mismatch, nsubstitute, nsubstitute-if,
nsubstitute-if-not, position, position-if, position-if-not, reduce,
remove, remove-if, remove-if-not, remove-duplicates, replace, search,
substitute, substitute-if, and substitute-if-not
- getting even more far-fetched, if tests with side-effects are allowed
(possibly in conjuction with :test or :test-if-not) a lot of the functions
in the previous item together with the following are possibilities:
assoc, assoc-if-not, member, member-if, member-if-not, adjoin, union,
nunion, intersection, nintersection, set-difference, nset-difference,
set-exclusive-or, nset-exclusive-or, subset, rassoc, rassoc-if,
rassoc-if-not, and pushnew.
- does GLS's clarification of (tailp '() L) imply that the following is legal?
(tailp '() '#0=(x . #0#))
I can imagine someone tastefully using everything down to and including dolist
with circular lists, even though I'd never use most of them myself. Below that
everything seems a revolting quagmire, and should explicitly "be an error."
Does COMMON LISP guarantee that we can successfully call inspect on a circular
list or structure? It should.
A related clarification. Not only can data be circular, so can code.
It should probably "be an error" to try to eval something like
(progn . #0=((f) . #0#)) ; an ugly way of saying (loop (f))
+ From: SCRC-STONY-BROOK.arpa!KMP@uw-beaver.UUCP (Kent M Pitman)
Certainly I've had a lot more use for NAND and NOR than for XOR.
Xor might be useful in that it avoids having to either repeat an expression or
introduce a let variable. This is what distinguishes it from nand and nor.
For example,
(nand
(one-of-my-special-expressions-p x)
(apply (get (first x) 'dispatcher) (rest x)) )
can be written
(not (and
(one-of-my-special-expressions-p x)
(apply (get (first x) 'dispatcher) (rest x)) ))
which isn't much hairier, while
(xor
(one-of-my-special-expressions-p x)
(apply (get (first x) 'dispatcher) (rest x)) )
can be written
(if (one-of-my-special-expressions-p x)
(not (apply (get (first x) 'dispatcher) (rest x)))
(apply (get (first x) 'dispatcher) (rest x)) )
or
(let* ((x (one-of-my-special-expressions-p x))
(y (apply (get (first x) 'dispatcher) (rest x))) )
(if x (not y) y) )
both of which are, I believe, hairier.
Such reasoning led me write an xor several times. But neither I nor anyone
else ever used the ones I wrote, as far as I can tell. Ever. It probably has
no place in the language, especially since the rare someone who actually needs
it a lot can easily enough write one.
+ Regarding adding the functions hash-table-rehash-size, hash-table-rehash-threshold,
hash-table-size, and hash-table-test:
- Would these be setf'able? I would expect the first two could be done easily,
and even the size and test can be changed by rehashing the table.
- What does hash-table-test return? 'eql or #'eql?
While on the subject of hash tables, here are a couple more points that have been
bothering me:
- Why is there no way to hash on arrays (other than bit-vectors and strings) and
structures? Should #'equalp hash tables also be supported? Things I would
have preferred to implement as structures I've implemented as lists,
defining accessors by hand, just so I can hash on them.
- Shouldn't it be made explicit that hash tables may store the actual key,
and that destructive operations should not be performed on it? Or is this
even true? I suppose one might expect a #'eq hash table to continue working
even if you mucked around with the keys stored in it, even though one would
probably not expect that of a #'equal hash table (yuk).
+ Regarding requiring that implementations support tracing of macros: What does
it mean to trace a macro? Do you just print information when the macro is
expanded, or do you arrange to have information printed every time the expansion
is eval'd? There are LISPs out there doing it each way.
+ Regarding globals: Standard LISP has the notion of a global. Nearly every
time I've modified a Standard LISP program that used globals extensively I've
had to change one or two of them to fluids (i.e. special) because something the
original implementor (often myself) thought no one would ever want to rebind I
neede to rebind. Even worse are the plethora of cases where somebody squirrels away
a global's value in a local, and restores it on the way back out (at least doing
this in COMMON LISP could be reasonably safe because of unwind-protect, which
Standard LISP lacks). Of course, these have always been shallow binding
implementations, where specials come for nearly free. I'd rather not see globals
introduced into the language, but deep binding implementations may really need
them, and it would be better to have one, standard mechanism than have each
deep binding implementation define its own incompatible one.
+ Not only would it be nice to be able to copy things involving structures, it
would be nice to be able to walk an arbitrary LISP object, including going
through structures. As near as I can tell, there's no portable way to walk
through the slots of an arbitrary structure. For example, how could one write
a recursive function which counted the number of occurances of the symbol 'foo
in an arbitrary LISP object which might contain, at any level, arbitrary
structures? Have I missed something? I get the feeling that there may have been
a deliberate decision to not allow this, but I'm not sure why.
+ I'm sure I'm being dense, but could someone explain two things from GLS's
list of clarifications to me?
- Why does (tailp '() L) return nil? I would have expected it to always
return t (I think that means that I would have thought the second sentence
of the description was right, and the first sentence was incorrect).
- Why does xor with more than two arguments do the odd/even stuff? I would
have expected it either to look for exactly one true value or exactly one
false, but not something as random as an odd number of trues.
+ (-: The obvious way to have an all-purpose undo function is to generalize setf
to work with an odd number of arguments:
(setf (symbol-function 'foo)) => (undefun 'foo)
(setf (symbol-value '*foov*)) => (mkunbound '*foov*) :-)
- Don Morrison
∂20-Dec-85 1203 FAHLMAN@C.CS.CMU.EDU fonts in CLtL
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Dec 85 12:03:38 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Dec 85 14:39:32-EST
Date: Fri, 20 Dec 1985 14:38 EST
Message-ID: <FAHLMAN.12168676959.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.ARPA
Cc: common-Lisp@SU-AI.ARPA
Subject: fonts in CLtL
In-reply-to: Msg of 19 Dec 1985 16:09-EST from Masinter.pa at Xerox.ARPA
I believe that all of us at CMU (I'm sure I'll be corrected if I'm
wrong) feel that the fonts attribute in a character is worthless. For
editor-like applications, it's too much work and too much wasted storage
to deal with this on a per-character basis. It might be useful for
extended character sets (e.g. Greek or Japanese), but not for the usual
use of switching between various sizes and shapes of Roman characters.
It's much better to use an additional data structure for that.
I've felt for some time that the bits attribute is also a bit misguided.
It seems to me that there are two distinct concepts that have become
muddled together: input keystroke objects, which are probably keyborad
or system dependent and which want to represent things like the various
flavors of shift and whether a keystroke came from the alphanumeric area
or the numeric keypad, and internal characters in some implementation
independent encoding suitable for stuffing into strings or shoving into
an output stream. The former has "bits" attached, but all you really do
with such things is pass them around, translate them to true characters,
dispatch on them, and maybe store them into a script of some sort.
This is not something to be changed lightly, but I agree with Masinter
that it is probably worth seeing whether anyone is really using these
thing sin the way that they were originally intended to be used. If
nobody is, or if the people using them also feel that they are not the
right thing, then we should think hard about making a change.
-- Scott
∂20-Dec-85 1211 gls@THINK-AQUINAS.ARPA GLS's clarifications list (moderately long)
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Dec 85 12:11:13 PST
Received: from wenceslas by GODOT.THINK.COM via CHAOS; Fri, 20 Dec 85 11:28:13 est
Date: Fri, 20 Dec 85 11:28 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: GLS's clarifications list (moderately long)
To: apollo!dfm@UW-BEAVER.ARPA, COMMON-LISP@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8512200453.AA03243@uw-beaver.arpa>
Message-Id: <851220112818.5.GLS@THINK-WENCESLAS.ARPA>
Date: Thu, 19 Dec 85 17:18:36 EST
From: apollo!dfm@uw-beaver.arpa
+ COMMON LISP's #n=/#n# syntax invites the creation of circular lists. For
example, the following seems more tasteful than the example with star, and
is, I believe, fairly perspicuous:
(mapcar #'cons p-list '#0=(property value . #0#))
Of course, the example with the STAR function:
(mapcar #'cons baz (star 'foo))
allows the value to be calculated at run time.
The obvious way to do it with #n= syntax is to use backquote:
(mapcar #'cons p-list `#0=(,property ,value . #0#))
but right now backquote is not defined to work on circular lists.
We could define it to do so (or maybe introduce `@ to handle the circular case).
Does COMMON LISP guarantee that we can successfully call inspect on a circular
list or structure? It should.
I agree, but it isn't addressed explicitly.
A related clarification. Not only can data be circular, so can code.
It should probably "be an error" to try to eval something like
(progn . #0=((f) . #0#)) ; an ugly way of saying (loop (f))
A LISP for the IBM 370 developed at Yorktown by Fred Blair and
colleagues actually made this work in both interpreter and compiler.
Fred was very proud of it.
+ Regarding globals: ... I'd rather not see globals
introduced into the language, but deep binding implementations may really need
them...
Actually, a trick that was designed for S-1 LISP may reduce the overhead
in deep-binding implementations: let there be a counter associated with
the global value cell, initially zero. Every time a deep binding of
that variable is created, the counter is incremented, and when the
binding is destroyed, the counter is decremented. Lookup of a special
variable proceeds as follows: first check the global counter. If it is
zero, just grab the global value cell. Otherwise do the usual
deep-binding search. Process-switching involves nothing new. Note that
if there are several processes, they share a single counter. The
counter merely serves as a hint: you might do the search even if you
didn't really have to (in the case where your process hasn't done a
special binding but some other process did), but in the truly global
case, no one has bound it and so the search is eliminated. It does
increase the cost of the lookup in the special case, but only by a
single zero check. One does have to be careful to destroy all bindings
(in order to adjust the counts) when a process is destroyed if the
efficiency is to be maintained.
+ (-: The obvious way to have an all-purpose undo function is to generalize setf
to work with an odd number of arguments:
(setf (symbol-function 'foo)) => (undefun 'foo)
(setf (symbol-value '*foov*)) => (mkunbound '*foov*) :-)
I would favor this quite a bit had not SETF been generalized to any even
number of argument forms rather than just two. With the generalization,
the chances for accidental lossage are too great. Maybe we could make one
argument form do an undo, but three or five would be illegal.
- Don Morrison
--Guy
∂20-Dec-85 1403 gls@THINK-AQUINAS.ARPA Multiple values and &optional
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Dec 85 14:03:00 PST
Received: from wenceslas by GODOT.THINK.COM via CHAOS; Fri, 20 Dec 85 17:03:02 est
Date: Fri, 20 Dec 85 17:03 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Multiple values and &optional
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
Just for the record, I had an application today where I really wanted to
write something like
(MULTIPLE-VALUE-BIND (VALUE &OPTIONAL (FOUNDP T))
(FUNCALL (MAGIC-HOOK-FUNCTION THINGY) FUNNY-ARG)
(WHEN FOUNDP
(CACHE-SOME-STUFF THINGY FUNNY-ARG VALUE))
(VALUES VALUE FOUNDP))
The context was that I wanted to have a user hook for a GETHASH-like
protocol, where a second return value indicates whether or not a goodie
was actually found. However, for convenience I wanted to allow the user
hook function to be any function that returns one thing as well, in
which case one assumes that the thing was found. In short, I wanted the
second return value to default to T, not NIL.
I ended up writing this instead:
(LET ((STUFF (MULTIPLE-VALUE-LIST
(FUNCALL (MAGIC-HOOK-FUNCTION THINGY) FUNNY-ARG))))
(WHEN (OR (NULL (CDR STUFF)) (CADR STUFF))
(CACHE-SOME-STUFF THINGY FUNNY-ARG (CAR STUFF)))
(VALUES-LIST STUFF))
--Guy
∂20-Dec-85 1636 DLW@SCRC-STONY-BROOK.ARPA GLS's clarifications list (moderately long)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Dec 85 16:36:13 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 379983; Fri 20-Dec-85 19:35:18-EST
Date: Fri, 20 Dec 85 19:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: GLS's clarifications list (moderately long)
To: gls@THINK-AQUINAS.ARPA, apollo!dfm@UW-BEAVER.ARPA,
COMMON-LISP@SU-AI.ARPA
In-Reply-To: <851220112818.5.GLS@THINK-WENCESLAS.ARPA>
Message-ID: <851220193530.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
I would like to point out that you are discussing the implementation
details of "globals" before we have agreed what "globals" are. There
were several interpretations of "globals" floating around on the mail
and no resolution of which one we were talking about.
∂20-Dec-85 2356 apollo!dfm@uw-beaver.arpa Re: Elegant rule for what to copy
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 20 Dec 85 23:55:56 PST
Received: by uw-beaver.arpa (4.42/4.2)
id AA15611; Fri, 20 Dec 85 22:43:24 PST
Return-Path: <apollo!dfm>
Message-Id: <8512210643.AA15611@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Fri, 20 Dec 85 10:49:08 EST
Subject: Re: Elegant rule for what to copy
To: uw-beaver!Rem%IMSSS
Cc: COMMON-LISP@su-ai.arpa
From: Rem@IMSSS@uw-beaver.UUCP
Subject: Elegant rule for what to copy
To: COMMON-LISP%SU-AI@SCORE
Interned symbols (IDs) will be
stop points, but GENSYMs will be recursed through, with another GENSYM of
exactly the same name replacing it, and with copies of the value and plist
and function. (In that case READing it back in would accidently INTERN all
the former GENSYMs, so COPY is more "right" than PRIN1-READ.)
That's not quite right, at least if *print-gensym* has its default value of t.
Instead a gensym would be prin1'd using #: notation, and read back in as a new
gensym with the same print name but *not* with the same plist, value, or function.
∂21-Dec-85 1724 Moon@SCRC-STONY-BROOK.ARPA Multiple values and &optional
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 Dec 85 17:21:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 380091; Fri 20-Dec-85 22:32:47-EST
Date: Fri, 20 Dec 85 22:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Multiple values and &optional
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
Message-ID: <851220222705.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
MULTIPLE-VALUE-CALL.
∂21-Dec-85 1738 NGALL@BBNG.ARPA Re: Multiple values and &optional
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Dec 85 17:37:57 PST
Date: 21 Dec 1985 18:20-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Multiple values and &optional
From: NGALL@BBNG.ARPA
To: gls@AQUINAS.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]21-Dec-85 18:20:32.NGALL>
In-Reply-To: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
Date: Fri, 20 Dec 85 17:03 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Multiple values and &optional
Message-ID: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
Just for the record, I had an application today where I really wanted to
write something like
(MULTIPLE-VALUE-BIND (VALUE &OPTIONAL (FOUNDP T))
(FUNCALL (MAGIC-HOOK-FUNCTION THINGY) FUNNY-ARG)
(WHEN FOUNDP
(CACHE-SOME-STUFF THINGY FUNNY-ARG VALUE))
(VALUES VALUE FOUNDP))
How about:
(multiple-value-call #'(lambda (value &optional (foundp t))
(when foundp
(cache-some-stuff thingy funny-arg value))
(values value foundp))
(magic-hook-function thingy))
And I agree that MULTIPLE-VALUE-BIND should be able to take a full-blown
lambda-list.
-- Nick
∂21-Dec-85 2102 NGALL@BBNG.ARPA Re: Multiple values and &optional
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Dec 85 17:37:57 PST
Date: 21 Dec 1985 18:20-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Multiple values and &optional
From: NGALL@BBNG.ARPA
To: gls@AQUINAS.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]21-Dec-85 18:20:32.NGALL>
In-Reply-To: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
Date: Fri, 20 Dec 85 17:03 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Multiple values and &optional
Message-ID: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
Just for the record, I had an application today where I really wanted to
write something like
(MULTIPLE-VALUE-BIND (VALUE &OPTIONAL (FOUNDP T))
(FUNCALL (MAGIC-HOOK-FUNCTION THINGY) FUNNY-ARG)
(WHEN FOUNDP
(CACHE-SOME-STUFF THINGY FUNNY-ARG VALUE))
(VALUES VALUE FOUNDP))
How about:
(multiple-value-call #'(lambda (value &optional (foundp t))
(when foundp
(cache-some-stuff thingy funny-arg value))
(values value foundp))
(magic-hook-function thingy))
And I agree that MULTIPLE-VALUE-BIND should be able to take a full-blown
lambda-list.
-- Nick
∂23-Dec-85 0030 MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA Comments
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Dec 85 00:30:45 PST
Received: from umass-cs by csnet-relay.csnet id a026470; 23 Dec 85 3:25 EST
Date: Sun, 22 Dec 85 17:15 EST
From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
To: common-lisp@su-ai.ARPA
Subject: Comments
I think the discussion about whether there should be an XOR
function is very much off the mark. I think the criterion for
including any new operator in the language should be one of
the following:
1) It is not possible to write it in Common Lisp.
2) It can be implemented MUCH more
efficiently in an implemention dependant way.
3) It requires a lot of programming effort (and is generally useful).
As long as an operator is implementable in Common Lisp, your program
would still be portable.
The only problem that could arise is that your function/macro
is called something that later on becomes defined in Common Lisp, with
different syntax/semantics. But that problem exists with ANY operator
that you define, and packages can deal with it. Thus I see no reason
to include something like XOR. The language is certainly big enough
already.
Other Issues:
I would like to vehemently disagree with the proposed change
to the mapping functions, such that it is an error to pass them
circular-lists. A see no advantage to this, and a clear
disadvantage (I use this mechanism, and often find it the clearest
way to express certain computation e.g.
(mapcar #'two-arg-fun arg1-list (or extra-arg-list (circular-list NIL))).
Moreoever, any implementation that actually Checked for the error
is certainly a foolish one.
It seems to me that the DEFGLOBAL proposal adds more confusion than
it could ever be worth. If the desire is to create a global variable
without taking chances on doing a dynamic binding of it, then it
seems the informal policy of doing *this* to a dynamic variable
is adequate. Anyone who does (let ((*something* ...))) is surely
begging to get a dynamic binding. Moreoever, it would seem to generate
no more efficiency.
;; I vote for eradication of MacroLet.
I recall someone has already asked for the inclusion of the
function MACROEXPAND-ALL. If this hasn't been accepted, I second
the motion on the grounds of criterion 3 above (It requires knowledge
of special-operators).
It appears that there is no way to return multiple values from
conditional forms in any useful way. COND,AND,OR don't return
multiple values for their predicate forms, except for the last form.
AND isn't problematic, since if it returns non-nil, it returns the
values of the last form, and hence multiple-values. It is OR that
is problematic. I find it unfortunate that something like:
(defun find-it (list parallel-list)
(cond ((null list) nil)
((and (atom list) (passes-test list))
(values list parallel-list))
(t (or (find-it (car list) (car parallel-list))
(find-it (cdr list) (cdr parallel-list))))))
Won't work since the OR won't return the multiple values
for the first (car) form. What is most distressing is
that OR WILL return multiple values for the last form. This
can easily create subtle bugs that are hard to figure out unless
you know of the peculiar behavior of OR. Of course, you can
give up on multiple-values, but it seems a real problem if you
have to resort to returning Lists in cases like these.
It is therfore my opinion that OR should return multiple values for ALL of it's
forms, or none of them. If the latter, Multiple-Value-OR can be written
in Common Lisp, but I wonder if it possible to do it more efficiently
in an implementation dependant way?
(BTW: Page 84 of Cltl refers to OR as a Special Form)
Random Functions:
I would also like to suggest the addition of the predicate
FILE-STREAM-P, which if true, would return the file pathname.
On the basis of being implementation dependant (criterion 1), I suggest
three more functions:
FUNCTION-ARGLIST, MACRO-ARGLIST, and FUNCTION-NAME.
These should work for system functions as well as user defined ones.
And for all kinds of functions - closures, compiled, interpreted.
- Kelly Murray
University Of Massachusetts
∂23-Dec-85 0756 NGALL@BBNG.ARPA Re: Comments
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 23 Dec 85 07:49:33 PST
Date: 23 Dec 1985 10:51-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Comments
From: NGALL@BBNG.ARPA
To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]23-Dec-85 10:51:26.NGALL>
In-Reply-To: The message of Sun, 22 Dec 85 17:15 EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Date: Sun, 22 Dec 85 17:15 EST
From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
To: common-lisp@su-ai.ARPA
Subject: Comments
I think the discussion about whether there should be an XOR
function is very much off the mark. I think the criterion for
including any new operator in the language should be one of
the following:
1) It is not possible to write it in Common Lisp.
2) It can be implemented MUCH more
efficiently in an implemention dependant way.
3) It requires a lot of programming effort (and is generally useful).
As long as an operator is implementable in Common Lisp, your program
would still be portable.
The only problem that could arise is that your function/macro
is called something that later on becomes defined in Common Lisp, with
different syntax/semantics. But that problem exists with ANY operator
that you define, and packages can deal with it. Thus I see no reason
to include something like XOR. The language is certainly big enough
already.
I would change criterion (3) to
3) It is generally useful and without it, ugly (i.e., opaque) idioms
must be used.
Since (I believe) the point is whether or not "everyone" is going to
implement it anyway, given that it is so useful. If they are, it
should be standardized, regardless of the implementation effort. So,
to me, the question concerning XOR is, will "everyone" use it? Since
I have NEVER been aware of the need for such a construct, I would vote NO.
...
I recall someone has already asked for the inclusion of the
function MACROEXPAND-ALL. If this hasn't been accepted, I second
the motion on the grounds of criterion 3 above (It requires knowledge
of special-operators).
I agree (on the grounds of my revised critterion 3).
...
Random Functions:
I would also like to suggest the addition of the predicate
FILE-STREAM-P, which if true, would return the file pathname.
On the grounds of what criteria?
On the basis of being implementation dependant (criterion 1), I suggest
three more functions:
FUNCTION-ARGLIST, MACRO-ARGLIST, and FUNCTION-NAME.
These should work for system functions as well as user defined ones.
And for all kinds of functions - closures, compiled, interpreted.
I heartily agree (at least about the first one)! I'm desperate for
such right now! I'm writing a profile module now and I'm "advising"
data collection calls around functions. And to make the advising
function as fast as possible I'd like it to have an "equivalent"
lambda-list.
For example, currently, I'm forced to write something like:
`(lambda (&rest arglist)
(start-data-collection)
(unwind-protect
(apply ',original-function arglist)
(stop-data-collection)))
which is SLOW (in most (?) implementations) due to both the use of
&REST and the use of APPLY.
If I could get the number of req. and opt. args and an indication of
whether or not a &rest arg (implicit or not) is required, I could
write something like the following:
(multiple-value-bind (req-args-count opt-args-count restp)
(parameter-info original-function)
(if (not restp)
(let ((req-args '())
(opt-args '()))
(dotimes (i req-args-count) (push (gensym) req-args))
(dotimes (i opt-args-count) (push (gensym) opt-args))
`(lambda (,@req-args &optional ,@opt-args)
(declare (inline ,original-function))
(start-data-collection)
(unwind-protect
`(,original-function ,@req-args &optional ,@opt-args)
(stop-data-collection))))
<code for the APPLY case (see above)>))
The above code if oversimplified. It assumes that the optional
parameters of the original-function all default to NIL and don't
contain <svar>s. But I hope you get the point.
Thus I recommend a function named PARAMETER-INFO that takes an
arg. of type (SATISFIES FUNCTIONP) and returns three values: the
number of required parameters (an integer), the number of optional
parameters (an integer), and either T or NIL depending on whether any
&REST or &KEYWORD parameters appear in the lambda-list. I believe
this information is retained (in all (?) implementations) even by
compiled code.
P.S. Does anyone know how I could get such info about a compiled
function definition in VaxLisp?!
-- Nick
∂23-Dec-85 0756 GSB@MC.LCS.MIT.EDU xor
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Dec 85 07:48:31 PST
Date: Mon, 23 Dec 85 10:51:14 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: xor
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].764612.851223.GSB>
What i don't like about XOR is that it sounds like it is in the same
class as AND and OR, and it is not all that like them. Like it or
not, AND and OR are control constructs. (I have never had any problem
with this, but Lisp is my first programming language. I am somewhat
disturbed by attempts to mask this nature of them -- they may lead to
even more confusion by this deemphasis.)
I wouldn't mind the functionality, but it's not clear to me that it is
worth too much confusion. As far as implementation is concerned, i
can see being able to implement this much better as a special operator
than as a macro.
∂23-Dec-85 0756 FAHLMAN@C.CS.CMU.EDU Comments
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Dec 85 07:56:00 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Dec 85 10:55:46-EST
Date: Mon, 23 Dec 1985 10:55 EST
Message-ID: <FAHLMAN.12169422751.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Comments
In-reply-to: Msg of 22 Dec 1985 17:15-EST from MURRAY%umass-cs.csnet at CSNET-RELAY.ARPA
I don't agree with Murray's three cirteria for what should go into the
language. I think a reasonable fourth criterion is:
4) The proposed construct will be used a lot, represents some
abstraction that is easy to grasp, and code using it is
clearer than the equivalent lower-level stuff appearing inline.
Actually, that's a criterion that every programmer should use in deciding
whether to create a new function or macro, but if the "used a lot" part
applies to the Common Lisp community as a whole and not just to one or
two application programs, then it is worthwhile putting this new thing
in.
This leads to a large language, but one in which there are lots of
useful constructs and one in which it is much easier for person A to
read person B's code. Murray's rules would lead to a very lean
language, perhaps easier to learn and a little bit easier to implement,
but not so good for heavy duty programming. For better or for worse, we
decided years ago that Common Lisp would include a lot of these optional
things. That is why, for example, we include all the sequence functions
that could just as easily have been written as DO's (or as PROG's and
GO's, for that matter.)
Of course, we've got to stop somewhere. Constructs whose usefulness is
unclear don't make it, nor do constructs where each person wants
something a little bit different and where there is no general agreement
on how to bundle these different versions into a single clear package.
If an item is controversial, but is implementable in a strictly portable
way, we generally suggest that it be put into a Yellow Pages library
until we see if it is going to "take" or not.
I don't like XOR because it doesn't look generally useful to me and
because it can be quite confusing to deal with. There are several
closely-related things that XOR might mean (only one versus odd parity,
for example) and the parallelism with AND and OR breaks down in
some ugly ways.
-- Scott
∂23-Dec-85 1029 REM%IMSSS.#Pup@SU-SCORE.ARPA Ground rules not yet decided???
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Dec 85 10:29:44 PST
Received: from IMSSS by Score with Pup; Mon 23 Dec 85 10:26:42-PST
Date: 23 Dec 1985 0828-PST
From: Rem@IMSSS
Subject: Ground rules not yet decided???
To: COMMON-LISP%SU-AI@SCORE
I thought the main reason for the big meeting this month was to
make a constitution and to decide basic ground rules such as what
rule of thumb should decide whether a given feature should be in CL or not?
Why are we still arguing over it? Wasn't it decided at the meeting?
I think the CL group should hurry up and decide these basic issues,
so our debate over details of this should be in and this should be out
won't be in a vacuum where only random personal opinions guide us.
-------
∂23-Dec-85 1323 JAR@MC.LCS.MIT.EDU unspecial & global & macrolet
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Dec 85 13:22:52 PST
Date: Mon, 23 Dec 85 16:25:37 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: unspecial & global & macrolet
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].764953.851223.JAR>
I don't much care whether DEFGLOBAL exists. But I will lobby for a
(declare (unspecial ...)) or (declare (lexical ...)), which provides the
sorely needed ability to do an assured lexical binding, independent of
the existence of a global special binding.
Does anyone have objections to the addition of an unspecial declaration?
I have asked about this twice before and haven't had any replies,
although I know there must be SOME reason it isn't in CLtL, since
Maclisp and the various Lisp Machine Lisps have it, and it must have
been considered.
I guess one objection is that for symmetry there ought to be a (proclaim
'(lexical ...)) to go with (declare (lexical ...)), and then we're
back to arguing about DEFGLOBAL again. But Common Lisp doesn't strike
me as a language in which symmetry and orthogonality play important
roles, so I don't see that this objection carries much weight; you could
have one and not the other.
---
I actually make good use of MACROLET; I think it's too late to eradicate
it, since many other users will be depending on it also.
Jonathan
∂23-Dec-85 1357 FAHLMAN@C.CS.CMU.EDU Ground rules not yet decided???
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Dec 85 13:55:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Dec 85 16:55:27-EST
Date: Mon, 23 Dec 1985 16:55 EST
Message-ID: <FAHLMAN.12169488230.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: Ground rules not yet decided???
In-reply-to: Msg of 23 Dec 1985 11:28-EST from Rem at IMSSS
In response to REM@IMSSS (mail sent to that address always bounces back
in my face):
It was never our intention to try to formalize the "ground rules"
covering the philosophy of language design at the Boston meeting or
anywhere else. This is a fluid process with a lot of varying opinions,
and in the end these choices come down to taste and experience. I don't
think it would be wise to try to chisel a set of principles in stone,
even if we could get people to agree.
What we did try to do in Boston was to work out some more formal way for
making final decisions on what is in Common Lisp and what is not. I had
assumed that everyone who cared about this had heard the news from
someone who attended the meeting, but maybe not. What happened in the
charter area was this (very briefly):
After some discussion of the possible kinds of organization we might
want to form, we heard from Bob Mathis on what it would take to
standardize Common Lisp in a formal way under ISO. Mathis used to run
the Ada and Stars programs at DOD, and he was deeply involved in the
effort to get Ada standardized by ISO. In the past, most of us had
discounted the formal standards organizations as unwieldy bureaucracies
that mangle everything they touch, but Mathis persuaded most of us that
there was a good chance of setting things up so that a technical
committee acceptable to the current Common Lisp community produces a
recommendation for a standard (perhaps a series of standards, one every
couple of years) and the ISO approves this as the standard definition of
Common Lisp without a lot of gratuitous alterations.
We decided that this route was worth a try. The original gang of five,
plus Mathis and Squires, were appointed to try to put together a
steering committee to do the political work and a technical commitee
that would be more representative of the total community than the gang
of five are by themselves. This will then be proposed to ISO, with
Mathis as the "convenor" of the committee -- a position of some power.
The formation of a separate standards organization for Common Lisp was
put on hold for six months, by which time we should have a good idea
whether the ISO process is going to work the way we want it to.
However, we hope to proceed rapidly toward getting ISI a contract from
DARPA for performing various non-decision-making support tasks for
Common Lisp.
The intention is that the technical committee, once formed, would work
in more or less the way that we always have worked. Issues would be
raised, discussed via the network (we hope to establish better mail
connections with Europe and Japan as quickly as possible), and when some
sort of near consensus emerges, a decision would be made and recorded.
The technical committee would then announce that this is going to be in
the proposed standard that is sent on to ISO. Eventually, all of these
decisions are bundled together, sent to ISO, and (we hope) they emerge
from the other end of the process as an ISO standard. Getting through
these last few steps could take a long time, but companies would be
perfectly free to go ahead and implement what is in the proposal, rather
than waiting for the final standard to be approved.
One thing that became clear at the meeting was that there is
considerable interest in Europe, especially in Jerome Chailloux's group
in France, in working on a smaller, cleaner Lisp that probably would be
a subset of Common Lisp. Of course, there has been some interest in
this in the U.S. as well, particularly in Kessler's PCLS group at Utah,
and Dr. Ida in Japan has been working on something similar.
I personally don't see any fundamental conflict here. What might well
emerge is a two-level standard (or maybe two distinct standards): big,
ugly, hairy industrial strength Common Lisp on the one hand, and some
cleaner subset on the other. (Whether the subset people can reach
agreement is another matter -- there are many different reasons for
doing a subset, and the resulting language would be different in each
case.) It would cause a lot of confusion to use the name "Common Lisp"
to refer to anything other than the big language more or less as defined
in Guy's book, but if we're careful in choosing what to call the subset,
the two levels should be able to coexist quite happily.
So the next task is to work out the membership of the technical and
steering committees, and then do whatever one does to get ISO to
recognize them. This will take awhile. In the meantime, nobody is in a
position to make any binding decisions on language issues, but we can
continue to muddle along as we have for the last year or two until the
more formal mechanism is in place.
-- Scott
∂23-Dec-85 2058 apollo!dfm@uw-beaver.arpa copy (moderately long message)
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 23 Dec 85 20:57:58 PST
Received: by uw-beaver.arpa (4.42/4.2)
id AA10071; Mon, 23 Dec 85 20:59:20 PST
Return-Path: <apollo!dfm@uw-beaver.arpa>
Message-Id: <8512240459.AA10071@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Mon, 23 Dec 85 17:03:01 EST
Subject: copy (moderately long message)
To: COMMON-LISP@su-ai.arpa
Cc: dfm
Here's a more detailed description of one possible version of copy. I believe this
combines most of the features people have suggested in recent mail and clarifies
most of the ambiguities people have pointed out in recent mail.
copy object &key :array :structure :hash-table :readtable :pathname :random-state
:gensym :fill-pointer :adjustable :level :circle
Recursively copies object as follows:
If object is a cons copy returns a new cons (i.e. it is guaranteed that
(and (consp object) (eq (copy object) object)) => nil) and calls itself
recursively to fill in the car and cdr.
If object is an array and :array is non-nil (it defaults to t) copy returns a new
array as follows:
The rank, dimensions, and element type are the same as object, subject to the
restrictions regarding fill pointers below. Even if object is displaced, the
result is not. The contents of the array are recursively copied. If an element
of the array is undefined (e. g. not initialized), it is undefined in the
result. In particular, if an implementation can recognize that an element
is undefined it need not copy that element.
Only if object has a fill pointer and :fill-pointer is non-nil will the result
have a fill pointer. The fill pointer is initialized to the same value as
object's fill pointer, and all the defined elements of object, even those that
are inactive with respect to the fill pointer, are copied. If the object has a
fill pointer but :fill-pointer is nil the result does not have a fill pointer,
and the length of the resulting vector is reduced to the current value of
object's fill pointer. :Fill-pointer defaults to nil.
Only if object is adjustable and :adjustable is non-nil is the result adjustable.
:Adjustable defaults to nil.
If object is a user defined structure and :structure is non-nil copy returns
a new structure of the same type. If object is named, the result acquires the
same name (i.e. if object is a user defined, named structure then
(eq (type-of object) (type-of (copy object)) => t). The values of the slots
of object are recursively copied to the result. If the value of a slot of object
is undefined, the value of the corresponding slot in the result is undefined.
In particular, if an implementation can recognize that a slot's value is
undefined it need not copy that slot. Any slots skipped over by the
:initial-offset option to defstruct are not recursively copied; that is, their
values in the result are eql to their values in object. :Structure defaults
to t.
If object is a hash table and :hash-table is non-nil copy returns a new hash table
whose size is at least as large as that of object, and with the same test,
rehash-size, and rehash-threshold. An entry is made in the new hash table for
each entry in object: keys are not recursively copied (i.e. the key in the new
table is eql to that in the old) but values are recursively copied. :Hash-table
defaults to nil.
If object is a readtable and :readtable is non-nil copy returns the same value as
(copy-readtable object). :Readtable defaults to nil.
If object is a pathname and :pathname is non-nil copy returns the same value as
(make-pathname :host (pathname-host object)
:device (pathname-device object)
:directory (pathname-directory object)
:name (pathname-name object)
:type (pathname-type object)
:version (pathname-version object) )
:Pathname defaults to t.
If object is a random state and :random-state is non-nil copy returns the same
value as (make-random-state object). :Random-state defaults to t.
If object is an uninterned symbol and :gensym is non-nil copy returns the same
value as (copy-symbol object). :Gensym defaults to t.
Otherwise copy simply returns a value eql to object.
The :level argument can be used to limit the depth of recursion. If supplied and
non-nil it should be a non-negative integer, in which case copy will only copy items
at that depth or shallower. For example, (copy object :level 1) copies only the top
level object itself. As a boundary case (copy object :level 0) returns object with-
out any copying. In the case of conses the depth is considered to increase only
through the cars, and not the cdrs; that is, an entire list is considered to be at
the same level. For example, if L is a list, then (copy L :level 1) returns the
same value as (copy-seq L). :Level defaults to nil.
If object is circular, or contains circular substructures, copy may fail to
terminate. If :circle is non-nil copy endeavors to detect cycles and terminate
normally, returning an isomorphic object. :Circle defaults to nil.
NOTES:
- The basic intention is that (copy object) be similar to
(read-from-string (write-to-string object :array t)), with objects that would be
printed using #< notation not being copied. Exactly what objects are printed
using #< notation is implementation dependent, and it seems best that the value
returned by copy be as implementation independent as possible. Therefore some
choices have to be made, mostly reflected in the defaults (e.g. I expect most
implementations to print hash tables using #<, but pathnames in some readable
format). These choices are obviously subjective.
- The reason no mechanism for preserving displacement in copying arrays is provided
is that displacement is typically an effort to deliberately avoid copying.
- It might seem strange to allow numeric and character keys in a #'eq hash table
to be copied (a la eql). However, I don't think that it can ever make sense to
use a #'eq hash table portably with numbers and characters.
- Note that copying a readtable, pathname, or random state may be a "shallow" copy.
However, since the structure of these items is not defined by the language it
seems incorrect to try to define it otherwise.
- No mechanism is supplied for copying interned ids or packages as that would appear
to raise some prohibitively awkward issues.
- No machinism is supplied for copying streams or functions, as the semantics of
these seem to be too implementation dependent.
- I see no reason why implementations couldn't allow copying other types of objects
by supplying more keyword arguments. Such extensions would, of course, not be
portable.
- Regarding :level and cdrs there seems to be a choice to be made between lists and
trees of conses. Lists are by far the more prevalent data structure so it seems
best to favor them. This also makes :level parallel the use of :level in write.
- One might expect that if there's a :level there should be a :length. This is
awkward for anything but lists, however. While I would expect
(copy '((1) (2) (3)) :length 2) to copy the first two elements but not the third,
what do I do about (copy '#((1) (2) (3)) :length 2)? One could say that we don't
copy the entire surrounding structure, and, for consistency, apply the same rule
to lists; the complexity of this seems to more than outweigh the dubious
usefulness of :length in copy.
- I believe that (equalp x (copy x)) => t. Indeed, the intermediate equality
predicate that Eric Benson proposed (case sensitive equalp) (and that I agree
is needed -- and should be supported as a hash table test) should also be true.
- I believe that this copy can easily be written in COMMON LISP, once the proposed
functions hash-table-size, etc. have been added, except for the code dealing with
structures. That implies to me that COMMON LISP probably needs more functionality
for manipulating structures. For example, I don't think that there is even a
portable way of even telling whether or not an object *is* a user defined
structure.
- Don Morrison
∂23-Dec-85 2058 α@uw-beaver.arpa
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 23 Dec 85 20:58:23 PST
Received: by uw-beaver.arpa (4.42/4.2)
id AA10088; Mon, 23 Dec 85 21:00:04 PST
Date: Mon, 23 Dec 85 21:00:04 PST
From: α@uw-beaver.arpa
Return-Path: <α@uw-beaver.arpa>
Message-Id: <8512240500.AA10088@uw-beaver.arpa>
Apparently-To: COMMON-LISP@SU-AI.ARPA
∂24-Dec-85 1530 gls@THINK-AQUINAS.ARPA Reader hacks
Received: from THINK.COM by SU-AI.ARPA with TCP; 24 Dec 85 15:30:50 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 23 Dec 85 16:49:47 est
Date: Mon, 23 Dec 85 16:47 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Reader hacks
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851223164735.3.GLS@THINK-JEHOSEPHAT.ARPA>
I am writing code for reader macros and find I need the following
things:
(1) A predicate that is true of whitespace characters and false
of all others. The problem is that
(member foo '(#\Space #\Newline))
doesn't cover tabs, etc., and
(member foo '(#\Space #\Newline #\Tab #\Form))
is not completely portable because of the semi-standard
character names.
(2) I find I can't easily write myself something akin to
READ-DELIMITED-LIST that handles dotted lists because of
the problem of recognizing all-dots tokens. PEEK-CHAR can
only peek one ahead, so I can't tell whether there is a
space after a dot before calling READ recursively.
--Guy
∂24-Dec-85 1535 gls@THINK-AQUINAS.ARPA GLS's clarifications list (moderately long)
Received: from THINK.COM by SU-AI.ARPA with TCP; 24 Dec 85 15:35:39 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 23 Dec 85 12:19:04 est
Date: Mon, 23 Dec 85 12:16 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: GLS's clarifications list (moderately long)
To: DLW@SCRC-QUABBIN.ARPA, apollo!dfm@UW-BEAVER.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <851220193530.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851223121647.1.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Fri, 20 Dec 85 19:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
I would like to point out that you are discussing the implementation
details of "globals" before we have agreed what "globals" are. There
were several interpretations of "globals" floating around on the mail
and no resolution of which one we were talking about.
You are quite right, of course. In my case that was intentional, but I
failed to make that clear. I was trying to explicate an alternative
semantics by proposing an implementation (not a specific one, but rather
one tied to DEFCONSTANT).
∂26-Dec-85 0934 Moon@SCRC-STONY-BROOK.ARPA Symbols as pathnames
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 09:34:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381485; Thu 26-Dec-85 12:33:42-EST
Date: Thu, 26 Dec 85 12:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Symbols as pathnames
To: common-lisp@SU-AI.ARPA
In-Reply-To: <851011153205.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851226122756.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 11 Oct 85 15:32 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Fri, 11 Oct 85 09:47:43 CDT
From: wagner@GSWD-VMS
On page 418 of CLtL, concerning the OPEN function: "The filename
...may be a string, a pathname, or a stream." May it not also be
a symbol, and shouldn't the spec say so? Same for WITH-OPEN-FILE,
etc.? (The underlying pathname functions work with symbols.)
It's true that most places in the manual say that symbols are acceptable
where pathnames are required, and are parsed as namestrings. I don't
understand why this feature is in there; it seems like asking for trouble.
What about implementations (yes they exist) where some streams are
implemented as symbols? How do you tell whether a symbol was supposed to
be a stream or supposed to be a string? What if NIL is accidentally used
where a pathname was expected, do you really want to get a file named "NIL"?
It's possible that the feature of allowing symbols as pathnames was blindly
copied from an old version of Zetalisp, which used to allow that. A couple
of bad ideas got into Common Lisp that way, in spite of significant effort
by the committee to try to keep it from happening. Zetalisp allowed symbols
for compatibility with an old version of pdp-10 Maclisp that didn't have
strings.
I never saw a response to the above. Now that we are discussing clarifications,
I'd like to suggest the following as a proposed clarification, to fix the fact
that in some places the manual says symbols are accepted as pathnames and in
other places it says they aren't. Symbolics' implementation currently contains
some inconsistencies in this area, which cannot be corrected without deviating
from what the manual currently says in one way or another. I'd prefer to see
all implementations deviate in the same direction.
If you reply to this message, please delete the enclosures from October, which
I only included for context.
p.413, 3rd paragraph: change "string or symbol" to "string" in both sentences.
p.413, pathname function: same.
p.414, 2nd to last paragraph: same.
p.417, pathname-host function, 1st sentence: same.
p.417, namestring function, 1st sentence: same.
p.414, parse-namestring function: delete the clause saying that @I[thing] may be
a symbol, in the second sentence.
p.415, merge-pathnames function, 3rd sentence: delete "or symbol".
p.424, probe-file function: Specify what @I[file] may be (I presume a string,
a pathname, or a stream).
p.423, rename-file function: change "@I[new-name] (which must be a filename)"
to "@I[new-name]." and add at the end of the first paragraph "@I[New-name] must
be a pathname, a string, or a stream." I see no reason to disallow streams
here; the conversion from stream to pathname is as defined by the PATHNAME function.
p.424, file-write-date and file-author functions, also GLS's proposed extension
to the file-length function: These use the term "filename", which I cannot find
defined elsewhere. Change "filename" to "pathname or string".
p.426, load function: This has an argument named "filename", whose type is not
defined. Define it to be a pathname, string, or stream--the same as the
argument named "filename" for open and with-open-file.
In chapter 23, there are arguments named pathname, thing, filename, file, and
name (really new-name). As far as I can tell there is no semantic difference
associated with these five different names. A consistent terminology should
be adopted. I suggest calling all of them pathname.
∂26-Dec-85 1012 Moon@SCRC-STONY-BROOK.ARPA XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 10:12:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381519; Thu 26-Dec-85 13:11:31-EST
Date: Thu, 26 Dec 85 13:05 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 22 Dec 85 17:15-EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Message-ID: <851226130548.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 22 Dec 85 17:15 EST
From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
I think the discussion about whether there should be an XOR
function is very much off the mark. I think the criterion for
including any new operator in the language should be one of
the following:
1) It is not possible to write it in Common Lisp.
2) It can be implemented MUCH more
efficiently in an implemention dependant way.
3) It requires a lot of programming effort (and is generally useful).
As long as an operator is implementable in Common Lisp, your program
would still be portable.
The only problem that could arise is that your function/macro
is called something that later on becomes defined in Common Lisp, with
different syntax/semantics. But that problem exists with ANY operator
that you define, and packages can deal with it. Thus I see no reason
to include something like XOR. The language is certainly big enough
already.
I agree completely. I could not have stated my position as clearly and
completely as you have.
[Rest of message, about other issues, not included in this particular reply]
∂26-Dec-85 1028 gls@THINK-AQUINAS.ARPA Comments
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Dec 85 10:28:07 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 26 Dec 85 13:27:58 est
Date: Thu, 26 Dec 85 13:28 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Comments
To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 22 Dec 85 17:15-EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Message-Id: <851226132828.4.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Sun, 22 Dec 85 17:15 EST
From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
I think the discussion about whether there should be an XOR
function is very much off the mark. I think the criterion for
including any new operator in the language should be one of
the following:
1) It is not possible to write it in Common Lisp.
2) It can be implemented MUCH more
efficiently in an implemention dependant way.
3) It requires a lot of programming effort (and is generally useful).
There should be a fourth criterion:
4) It is so useful that many individual users keep reinventing it,
and therefore it is deserving of standardization.
PUSH and POP fall into this category, for example. On the other hand, I
will not argue that XOR does fall into this category, as all the
reent evidence on the mailing list indicates otherwise.
Several others have also pointed out the potential ambiguity in extending
XOR to more than two arguments: is it "an odd number true", "exactly one
true", or "all but one true" (the latter being unlikely given the name,
but nevertheless a consistent extension)? The main reason for choosing
"an odd number true" is that that definition is associative, whereas the
other choices are not. If XOR were to be added to the language (and I will
not argue strongly that it should be), I would suggest making it a function
(not a special form) of exactly two arguments (to avoid the ambiguity).
I do not find convincing the argument against XOR on the grounds that
it cannot terminate its execution early the way AND and OR do. After all,
NOT is usually in the same bag as AND and OR, and it is not a special form.
I would say that XOR is more like NOT than like AND and OR.
--Guy
∂26-Dec-85 1054 Moon@SCRC-STONY-BROOK.ARPA Reader hacks
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 10:54:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381574; Thu 26-Dec-85 13:52:11-EST
Date: Thu, 26 Dec 85 13:46 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Reader hacks
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851223164735.3.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851226134628.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 23 Dec 85 16:47 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
I am writing code for reader macros and find I need the following
things:
(1) A predicate that is true of whitespace characters and false
of all others. The problem is that
(member foo '(#\Space #\Newline))
doesn't cover tabs, etc., and
(member foo '(#\Space #\Newline #\Tab #\Form))
is not completely portable because of the semi-standard
character names.
Is this something different from
(or (char-equal char #\space)
(not (graphic-char-p char))) ?
(2) I find I can't easily write myself something akin to
READ-DELIMITED-LIST that handles dotted lists because of
the problem of recognizing all-dots tokens. PEEK-CHAR can
only peek one ahead, so I can't tell whether there is a
space after a dot before calling READ recursively.
How about a way (a special variable?) to turn off the somewhat silly
restriction that you can't have a symbol named .? Alternatively,
how about a function that does the token-isolating portion of READ
but not the printed-representation-to-object conversion portion of
READ?
∂26-Dec-85 1139 Bobrow.pa@Xerox.ARPA Re: copy
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 11:39:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 DEC 85 11:39:17 PST
Date: 26 Dec 85 11:39 PST
From: Bobrow.pa@Xerox.ARPA
Subject: Re: copy
To: dfm@uw-beaver.arpa
cc: COMMON-LISP@su-ai.arpa
Message-ID: <851226-113917-1685@Xerox>
If we adopt something like CommonLoops where all objects have an
associated class, then the Copy problem becomes factored in a different
way; that is, one independently decides for each class the response to
two messages, COPY and COPY-IN:
COPY is the top level call. It produces a copy if it can
e.g. a new cons pair, same symbol, but a copy of a named structure
(unnamed).
COPY-IN is the recursive call. Each type determines whether to return
itself or a copy for inclusion in a larger structure.
The protocol suggested by dfm is probably the appropriate definition for
COPY-IN. For named objects, COPY and COPY-IN would differ. For CONSes
they would be the same, etc.
danny
∂26-Dec-85 1240 LOOSEMORE@UTAH-20.ARPA BOA constructor questions
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 12:40:04 PST
Date: Thu 26 Dec 85 13:38:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: BOA constructor questions
To: common-lisp@SU-AI.ARPA
Message-ID: <12170260722.11.LOOSEMORE@UTAH-20.ARPA>
It is not clear from the discussion of BOA constructors in the manual what
is supposed to happen if you don't mention all the slot names in the arglist,
or even that it's legal to omit slots from the arglist. Presumably, the
omitted slots should be initialized to whatever default value was given in
the body of the defstruct; if this is the case, the manual should say so.
Perhaps a better example would help.
Also, it says that "the keywords &optional, &rest, and &aux are recognized
in the argument list". Is there a reason why &key is not permitted? Or
is this an oversight?
-Sandra
-------
∂26-Dec-85 1309 gls@THINK-AQUINAS.ARPA BOA constructor questions
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Dec 85 13:09:07 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 26 Dec 85 16:09:15 est
Date: Thu, 26 Dec 85 16:09 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: BOA constructor questions
To: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <12170260722.11.LOOSEMORE@UTAH-20.ARPA>
Message-Id: <851226160949.7.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Thu 26 Dec 85 13:38:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
It is not clear from the discussion of BOA constructors in the manual what
is supposed to happen if you don't mention all the slot names in the arglist,
or even that it's legal to omit slots from the arglist. Presumably, the
omitted slots should be initialized to whatever default value was given in
the body of the defstruct; if this is the case, the manual should say so.
Perhaps a better example would help.
Also, it says that "the keywords &optional, &rest, and &aux are recognized
in the argument list". Is there a reason why &key is not permitted? Or
is this an oversight?
-Sandra
-------
I don't see any technical reason why &KEY should not be permitted, with
semantics analogous to those for &OPTIONAL. Then the standard
constructor function can be explained as a special case the more general
constructor feature that happens to take an argument for every slot and
takes them all as &KEY arguments.
But this prompts in me another question: does
(defstruct (foo (:constructor build-foo (&optional baz &aux baz)))
(baz 5))
mean that
(make-foo) initializes BAZ to 5
(make-foo :baz 43) initializes BAZ to 43
(build-foo 91) initializes BAZ to 91
(build-foo) *does not initialize* BAZ ?
If not, how else can I say it? (Never mind why I would want to.)
--Guy
∂26-Dec-85 1342 GSB@MC.LCS.MIT.EDU Reader hacks
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 13:42:18 PST
Date: Thu, 26 Dec 85 16:45:01 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: Reader hacks
To: Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
Message-ID: <[MC.LCS.MIT.EDU].766640.851226.GSB>
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
I am writing code for reader macros and find I need the following
things:
(1) A predicate that is true of whitespace characters and false
of all others. . . .
Is this something different from
(or (char-equal char #\space)
(not (graphic-char-p char))) ?
Well, i was going to say that backspace didn't fit this mold, but CLtM
says it isn't a token constituent unless quoted. Oh well. Anyway,
have we ever speculated on the relationship of predicates like
graphic-char-p or this hypothetical whitespace-p, and readtables? How
well-defined is it to transfer the syntax of one character to another?
(2) I find I can't easily write myself something akin to
READ-DELIMITED-LIST that handles dotted lists because of
the problem of recognizing all-dots tokens. PEEK-CHAR can
only peek one ahead, so I can't tell whether there is a
space after a dot before calling READ recursively.
How about a way (a special variable?) to turn off the somewhat silly
restriction that you can't have a symbol named .?
Flushing the restriction of unquoted all-dots tokens would only
ameliorate the problem a bit, because he would still have to read the
token himself because he wouldn't be able to unread-char both the dot
and the following token. Besides all the other stuff which is almost
what read-delimited-list provides. Restated, the problem is that one
might want read-delimited-list to barf about cons dots; for instance,
to implement #( syntax. Alternatively, one might want to do
variations of ordinary parentheses in which cons-dot is meaningful.
So having some sort of flag argument to read-delimited-list makes
sense.
Alternatively, how about a function that does the token-isolating
portion of READ but not the printed-representation-to-object
conversion portion of READ?
Do you think this could be done without over half the implementors
having apoplectic fits, and with no loss of life?
∂26-Dec-85 1628 REM%IMSSS.#Pup@SU-SCORE.ARPA COPY and COPY-IN
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 16:28:28 PST
Received: from IMSSS by Score with Pup; Thu 26 Dec 85 16:25:19-PST
Date: 26 Dec 1985 1625-PST
From: Rem@IMSSS
Subject: COPY and COPY-IN
To: Bobrow.pa%Xerox.ARPA@SCORE
cc: COMMON-LISP%SU-AI@SCORE
Do I understand your proposed semantics correctly, that at the very top
level COPY will force-copy a named object creating an unnamed object with
all the same parts as the original but not EQ to it and inaccessible via
the oblist, but recursively an object is copied if and only if it isn't
named, being a recursion-stop-point if it is named?
(at least that's the proposed default, which could be overriden by
keyword parameters to COPY which become fluid parameters accessed by COPY-IN)
-------
∂26-Dec-85 1706 @SU-SCORE.ARPA:Bobrow.pa@Xerox.ARPA Re: COPY and COPY-IN
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 17:05:59 PST
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Thu 26 Dec 85 17:02:36-PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 DEC 85 17:05:48 PST
Date: 26 Dec 85 17:05 PST
From: Bobrow.pa@Xerox.ARPA
Subject: Re: COPY and COPY-IN
In-reply-to: Rem@IMSSS.ARPA's message of 26 Dec 85 16:25 PST
To: Rem@IMSSS.ARPA
cc: Bobrow.pa%Xerox.ARPA@SU-SCORE.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA
Message-ID: <851226-170548-1750@Xerox>
Do I understand your proposed semantics correctly, that at the very
top
level COPY will force-copy a named object creating an unnamed object
with
all the same parts as the original but not EQ to it and inaccessible
via
the oblist, but recursively an object is copied if and only if it
isn't
named, being a recursion-stop-point if it is named?
(at least that's the proposed default, which could be overriden by
keyword parameters to COPY which become fluid parameters accessed by
COPY-IN)
-------
I would propose that the top level COPY will force-copy (if that makes
sense); but what it does is determined by a METHOD associated with the
class of the object.
Similarly, the recursion is controlled by the COPY-IN METHOD for each
class. A class could have its own specific response to
keyword-parameters.
∂26-Dec-85 1959 Moon@SCRC-STONY-BROOK.ARPA XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 19:59:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381615; Thu 26-Dec-85 14:36:40-EST
Date: Thu, 26 Dec 85 14:30 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 22 Dec 85 17:15-EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Supersedes: <851226130548.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851226143056.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 22 Dec 85 17:15 EST
From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
I think the discussion about whether there should be an XOR
function is very much off the mark. I think the criterion for
including any new operator in the language should be one of
the following:
1) It is not possible to write it in Common Lisp.
2) It can be implemented MUCH more
efficiently in an implemention dependant way.
3) It requires a lot of programming effort (and is generally useful).
As long as an operator is implementable in Common Lisp, your program
would still be portable.
The only problem that could arise is that your function/macro
is called something that later on becomes defined in Common Lisp, with
different syntax/semantics. But that problem exists with ANY operator
that you define, and packages can deal with it. Thus I see no reason
to include something like XOR. The language is certainly big enough
already.
I agree completely. I could not have stated my position as clearly and
completely as you have.
LATER: I also agree with the other people who said that a 4th criterion
should be added, that enough people will use it that it's important to
standardize the name, even though everyone could implement it for themselves.
They seemed to think that by saying this they were disagreeing with you,
but I didn't read what you said as disagreeing with that sentiment.
[Rest of message, about other issues, not included in this particular reply]
∂26-Dec-85 2000 Moon@SCRC-STONY-BROOK.ARPA RE: Symbols as pathnames
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85 19:59:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381627; Thu 26-Dec-85 14:55:15-EST
Date: Thu, 26 Dec 85 14:49 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: RE: Symbols as pathnames
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 26 Dec 85 14:47-EST from "BACH::NELSON" <nelson%bach.decnet@hudson.dec.com>
Message-ID: <851226144932.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 12/26/85 14:47
From: "BACH::NELSON" <nelson%bach.decnet@hudson.dec.com>
By choosing one from the list of pathname, filename, etc. to refer
to pathnames, streams, and strings, did you mean that an argument
called pathname could be any of those three types? If you meant
that the word pathname actually means "pathname, symbol or string"
when used in the text of the book, that seems confusing; while a statement
that an argument called "pathname" could be a pathname, string, or
stream seems helpful.
I meant the latter; sorry to be ambiguous.
If, by the way, the approach is to enumerate
those three types under each function in chapter 23, it would probably
be a god idea to do so for the pathname argument to require, as well.
Thanks, I missed that one. Consider it added to my proposal.
∂27-Dec-85 0320 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU GLS's clarifications list (moderately long)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Dec 85 03:20:44 PST
Received: from JANIS.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 27 Dec 85 06:26-EST
Date: Fri, 27 Dec 85 06:21 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: GLS's clarifications list (moderately long)
To: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <8512200453.AA03243@uw-beaver.arpa>
Message-ID: <851227062125.6.CFRY@JANIS.AI.MIT.EDU>
+ (-: The obvious way to have an all-purpose undo function is to generalize setf
to work with an odd number of arguments:
(setf (symbol-function 'foo)) => (undefun 'foo)
(setf (symbol-value '*foov*)) => (mkunbound '*foov*) :-)
Not obvious to me, even if there's only one argument.
The overloading of the semantics of setf is clever ...
which is exactly why I'd prefer the function that does
the undo semantics to be spelled differently than "setf" .
To me (setf (accessor ...)) implies setting the thing to NIL,
but I wouldn't want setf to have that semantics either.
∂27-Dec-85 0530 GJC@MC.LCS.MIT.EDU Reader hacks
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Dec 85 05:30:41 PST
Date: Fri, 27 Dec 85 08:33:24 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Reader hacks
To: GSB@MC.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM,
Moon@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Thu 26 Dec 85 16:45:01 EST from Glenn S. Burke <GSB at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].767075.851227.GJC>
A reader should be able to be a portable common lisp program right?
Maybe if a sufficiently flexible reader could be published then people like
GLS could use it.
∂27-Dec-85 1054 LOOSEMORE@UTAH-20.ARPA Another inconsistency in CLtL
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 Dec 85 10:54:16 PST
Date: Fri 27 Dec 85 11:53:01-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Another inconsistency in CLtL
To: common-lisp@SU-AI.ARPA
Message-ID: <12170503603.18.LOOSEMORE@UTAH-20.ARPA>
The specification for INTERN describes the optional "package" argument as
being a package, not a package name. However, the discussion of #S syntax
for reading structures on page 357 shows INTERN being called with the
"package" argument being the symbol 'keyword. Should this actually be
(find-package 'keyword), or have I missed something in the packages chapter
that says arguments named "package" can be either packages or package names?
-Sandra
-------
∂28-Dec-85 1509 Moon@SCRC-YUKON.ARPA BOA constructor questions
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 28 Dec 85 15:09:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 182987; Sat 28-Dec-85 18:04:58-EST
Date: Sat, 28 Dec 85 18:02 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: BOA constructor questions
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, LOOSEMORE@UTAH-20.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851226160949.7.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851228180256.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 26 Dec 85 16:09 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Thu 26 Dec 85 13:38:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
It is not clear from the discussion of BOA constructors in the manual what
is supposed to happen if you don't mention all the slot names in the arglist,
or even that it's legal to omit slots from the arglist. Presumably, the
omitted slots should be initialized to whatever default value was given in
the body of the defstruct; if this is the case, the manual should say so.
Perhaps a better example would help.
I agree with your interpretation and with the suggestion for improving the manual.
Also, it says that "the keywords &optional, &rest, and &aux are recognized
in the argument list". Is there a reason why &key is not permitted? Or
is this an oversight?
I don't see any technical reason why &KEY should not be permitted, with
semantics analogous to those for &OPTIONAL.
Indeed. It works with the obvious semantics in our implementation.
Then the standard
constructor function can be explained as a special case the more general
constructor feature that happens to take an argument for every slot and
takes them all as &KEY arguments.
But this prompts in me another question: does
(defstruct (foo (:constructor build-foo (&optional baz &aux baz)))
(baz 5))
mean that
(make-foo) initializes BAZ to 5
(make-foo :baz 43) initializes BAZ to 43
(build-foo 91) initializes BAZ to 91
(build-foo) *does not initialize* BAZ ?
If not, how else can I say it? (Never mind why I would want to.)
Isn't this in conflict with your (Guy's) suggested clarification to page 60,
that a function may not have two parameters with the same name? If that clarification
was not intended to apply to &AUX variables, you didn't say so.
The way I read the Common Lisp manual, your example defstruct above does not
define any function named make-foo. You'd have to say
(defstruct (foo (:constructor build-foo (&optional baz &aux baz))
(:constructor make-foo))
(baz 5))
if you wanted that.
I think the answer to "how else can I say it?" is that you can't say
it except by being more explicit and verbose, e.g.
(defstruct (foo (:constructor build-foo (&optional baz))
(:constructor make-foo (&key (baz 5))))
baz)
∂28-Dec-85 1533 edsel!eb@su-navajo.arpa Tail recursive Common Lisp interpreter?
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 28 Dec 85 15:33:25 PST
Received: by su-navajo.arpa with Sendmail; Sat, 28 Dec 85 15:30:24 pst
Received: by edsel.uucp (2.2/SMI-2.0)
id AA12247; Sat, 28 Dec 85 15:15:18 pst
Date: Sat, 28 Dec 85 15:15:18 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8512282315.AA12247@edsel.uucp>
To: navajo!Common-Lisp@SU-AI
Subject: Tail recursive Common Lisp interpreter?
Recently, we added a new feature to our compiler: general tail-recursion
removal. That is, when FOO returns the value of calling BAR, there is
no need to grow the stack; BAR can use the same stack frame as FOO and
return to its caller. Scheme requires this behavior, so that iteration
can be defined in terms of recursion. Scheme supporters tend to get
irate about Lisp implementations which do not have this behavior. In
fact, they call this "properly tail-recursive," giving a moral tone to
the whole issue.
When I wrote our interpreter, I tried to be very careful so that if it
were compiled with a compiler which does tail recursion elimination, it
too would be properly tail recursive. Finally, I had a chance to try it
out. I compiled EVAL, loaded it in and typed
(DEFUN FOO (X)
(IF (ZEROP X)
(BREAK)
(FOO (1- X))))
(FOO 10)
thus entering the debugger, expecting to find no frames on the stack.
To my dismay, I saw 10 BLOCK frames. Then it dawned on me: every DEFUN
wraps a BLOCK around the body, so that I would have been able to say
(RETURN-FROM FOO ...) anywhere in my definition. BLOCK is implemented
with a CATCH in the interpreter, and the last call of a CATCH is not
tail recursive; the CATCH frame must be removed from the stack before
returning. Even FLET and LABELS aren't tail recursive, for the same
reason, due to our recent extension to them of the "implicit BLOCK"
feature. Only raw LAMBDAs are truly tail recursive.
I would like to change this, but I don't want to do a lot of static
analysis in the interpreter. That tends to defeat the purpose of EVAL,
which I take to be fast turnaround time in testing code. I can't see
any other way of implementing the implicit BLOCK except using CATCH or
some other mechanism which defeats tail recursion. Does anyone have any
clever ideas for solving this problem?
∂28-Dec-85 1636 GJC@MC.LCS.MIT.EDU Tail recursive Common Lisp interpreter?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Dec 85 16:36:04 PST
Date: Sat, 28 Dec 85 19:38:46 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Tail recursive Common Lisp interpreter?
To: edsel!eb@SU-NAVAJO.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Sat 28 Dec 85 15:15:18 pst from edsel!eb at su-navajo.arpa (Eric Benson)
Message-ID: <[MC.LCS.MIT.EDU].767631.851228.GJC>
Thats an extremely interesting discovery. One known way to win: You
can implement an explicit control evaluator like one might in Scheme.
The control-point from a block then falls out like schemes lexical
catch contruct does. Or, what is easier, given a Scheme with lexical catch,
write your Common-Lisp interpreter in that.
Here is another tail-recursion story. One of Papert's hackers was relating
to me one day how LOGO was tail recursive even though it used shallow
binding, and how that this was a pretty clever thing (to pull off)
So I said, ok, lets try to write:
(DEFUN IFACT (N ACC) (IF (ZEROP N) ACC (IFACT (1- N) (* N ACC))))
and thus (DEFUN FACT (N) (IFACT N 1)). Well, my first try didnt work
at all, in fact, it didnt return ANY VALUE. I was then told that, OH,
to return a value you have to use OUTPUT. Thus (excuse the inexact logo syntax)
TO IFACT :N :ACC IF N=0 OUTPUT ACC ELSE OUTPUT IFACT N-1 N*ACC
well, the OUTPUT caused the tail recursion to be broken.
Or, you cant teach an ancient dog old tricks.
Or, you can dress the language up but you cant take it ...
∂29-Dec-85 1415 DCP@SCRC-STONY-BROOK.ARPA Multiple values and &optional
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Dec 85 14:15:51 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 382604; Sun 29-Dec-85 17:15:01-EST
Date: Sun, 29 Dec 85 17:18 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Multiple values and &optional
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>,
Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851220222705.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851229171821.7.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Fri, 20 Dec 85 22:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
MULTIPLE-VALUE-CALL.
Not only is that the right answer, but recall that MULTIPLE-VALUE-BIND
is a MACRO, so says CLtL, and as far as I know the only way that macro
can expand into special forms and functions defined in CLtL is via
MULTIPLE-VALUE-CALL.
∂29-Dec-85 1524 NGALL@BBNG.ARPA Re: Reader hacks
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 29 Dec 85 15:24:02 PST
Date: 29 Dec 1985 18:21-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Reader hacks
From: NGALL@BBNG.ARPA
To: gls@AQUINAS.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]29-Dec-85 18:21:24.NGALL>
In-Reply-To: <851223164735.3.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Mon, 23 Dec 85 16:47 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Reader hacks
Message-ID: <851223164735.3.GLS@THINK-JEHOSEPHAT.ARPA>
I am writing code for reader macros and find I need the following
things:
(1) A predicate that is true of whitespace characters and false
of all others. The problem is that
(member foo '(#\Space #\Newline))
doesn't cover tabs, etc., and
(member foo '(#\Space #\Newline #\Tab #\Form))
is not completely portable because of the semi-standard
character names.
How about?:
(defun whitespace-p (char)
(with-input-from-string (input-string (string char))
(null (peek-char t input-string nil nil nil))))
If char is a whitespace char., PEEK-CHAR will hit EOF and return NIL;
otherwise PEEK-CHAR will return the char. Inefficient, but the only
portable solution I know.
I think there should be a function
SYNTAX-TYPE char => {ILLEGAL | WHITESPACE | CONSTITUENT |
SINGLE-ESCAPE | MULTIPLE-ESCAPE | MACRO}
-- Nick
∂30-Dec-85 0237 REM@IMSSS Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1985-Dec-30 02:31:40 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1985 December 29 23:21:04 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132535112014.G0353
From: Robert Elton Maas <REM@IMSSS.STANFORD.EDU>
To:edsel!eb@su-navajo.arpa
CC:COMMON-LISP@SU-AI
Subject:Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until IMSSS.STANFORD.EDU registered)
Date: 28 Dec 1985 1824-PST
From: Rem@λIMSSSλ
Subject: I favor flushing implicit catch frames except where appropriate
To: edsel!eb%su-navajo.arpa@λSCOREλ
cc: COMMON-LISP%SU-AI@λSCOREλ
Your message is very interesting. It sounds like CL in forcing the
availibility of RETURN-FROM just about everywhere in the language has
accidently forbid efficient tail recursion except when an optimizing
compiler has gone around and flushed unneeded RETURN-FROM (CATCH) frames.
If you are correct, I would favor flushing this default behaviour of
CL, instead requiring programmers to say explicitly when some PROG or
LET might need the RETURN-FROM capability.
When I want to do a non-local return, I first think of THROW/CATCH, which
is completely general, and not of RETURN-FROM. Something like 99% of
PROGs and LETs et al are simple, don't need a non-local return mechanism.
Let's take a survey. Is there anyone who programs in such a way that any
significant fraction of PROGs or LETs et al make use of RETURN-FROM?
Is there anyone would have to rewrite a lot of code if RETURN-FROM frames
weren't implicit everywhere in the language. Would anyone object to
requiring explicit CATCH where nonlocal return frames are desired?
P.S. Normally all those extra frames are useful during debugging, so
when something bombs out you can look up the recursion stack and see
all the calls and jcalls still on the stack instead of just the calls
(notation: jcall = tail-recursion, call = true-recursion). But often
one has an interpreted function that is highly recursive but where
those extra frames aren't useful and cause stack overflow, so I can see
the value in being able to disable the creation of tail-recursion frames,
and I second the motion to maybe flush them.
-------
∂30-Dec-85 0601 GJC@MC.LCS.MIT.EDU tail recursion in CL interpreters.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Dec 85 06:01:39 PST
Date: Mon, 30 Dec 85 09:04:23 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: tail recursion in CL interpreters.
To: REM%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-reply-to: Msg of 1985 Dec 29 23:21:04 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.STANFORD.EDU>
Message-ID: <[MC.LCS.MIT.EDU].768550.851230.GJC>
Did my reply get lost or something? It explained how you could write
an interpreter with tail recursion even with all the implicit BLOCK
statements.
∂30-Dec-85 0832 gls@THINK-AQUINAS.ARPA BOA constructor questions
Received: from THINK.COM by SU-AI.ARPA with TCP; 30 Dec 85 08:32:29 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Mon, 30 Dec 85 11:32:39 est
Date: Mon, 30 Dec 85 11:32 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: BOA constructor questions
To: Moon@SCRC-STONY-BROOK.ARPA, gls@THINK-AQUINAS.ARPA, LOOSEMORE@UTAH-20.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <851228180256.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <851230113242.2.GLS@THINK-YON.ARPA>
Date: Sat, 28 Dec 85 18:02 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Thu, 26 Dec 85 16:09 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
...
But this prompts in me another question: does
(defstruct (foo (:constructor build-foo (&optional baz &aux baz)))
(baz 5))
mean that
(make-foo) initializes BAZ to 5
(make-foo :baz 43) initializes BAZ to 43
(build-foo 91) initializes BAZ to 91
(build-foo) *does not initialize* BAZ ?
If not, how else can I say it? (Never mind why I would want to.)
Isn't this in conflict with your (Guy's) suggested clarification to page 60,
that a function may not have two parameters with the same name? If that clarification
was not intended to apply to &AUX variables, you didn't say so.
Yes, I suppose it is; but then the interpretation of &AUX variables in
this context is completely crocky anyway. I think I prefer to have the
very simple rule that no duplicate names are permitted within a single
parameter list, period. One can come up with reasonable interpretations
in many special cases, but such cases are probably all very poor
examples of style.
The way I read the Common Lisp manual, your example defstruct above does not
define any function named make-foo. You'd have to say
(defstruct (foo (:constructor build-foo (&optional baz &aux baz))
(:constructor make-foo))
(baz 5))
if you wanted that.
Funny. I always thought that the normal constructor always gets created
unless explicitly suppressed with (:constructor nil), BOA constructors
being irrelevant to the question. However, I now find that the prose at
the bottom of page 315 is horribly ambiguous.
I think the answer to "how else can I say it?" is that you can't say
it except by being more explicit and verbose, e.g.
(defstruct (foo (:constructor build-foo (&optional baz))
(:constructor make-foo (&key (baz 5))))
baz)
This sounds fine to me. This might be awkward if "5" were a very large
expression and I wanted three constructors, two of which initialize slot
BAZ, but I am not going to lose sleep over it.
--Guy
∂30-Dec-85 1231 JAR@MC.LCS.MIT.EDU Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Dec 85 12:30:40 PST
Date: Mon, 30 Dec 85 15:33:21 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
To: REM%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA, edsel!eb@SU-NAVAJO.ARPA
In-reply-to: Msg of 1985 Dec 29 23:21:04 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.STANFORD.EDU>
Message-ID: <[MC.LCS.MIT.EDU].768914.851230.JAR>
Date: 1985 December 29 23:21:04 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.STANFORD.EDU>
Your message is very interesting. It sounds like CL in forcing the
availibility of RETURN-FROM just about everywhere in the language has
accidently forbid efficient tail recursion except when an optimizing
compiler has gone around and flushed unneeded RETURN-FROM (CATCH) frames.
If you are correct, I would favor flushing this default behaviour of
CL, instead requiring programmers to say explicitly when some PROG or
LET might need the RETURN-FROM capability.
As GJC correctly points out, Scheme has always had a lexical catch (i.e.
block/return) which is implementable in such a way that catches incur no
net stack growth, and no static code analysis is needed. The usual way
to do this allocates the control point (either a stub pointing into the
control stack, or the entire control stack) in the heap, but there are
more or less hairy alternative implementation strategies which do less
heap allocation (none, most of the time). I don't think this problem is
much different from that of allocating storage for lexical environments,
which if not done carefully also threatens tail recursion.
So tail-recursion is not a reason to flush implicit blocks. (I can
think of other reasons, but that's not the point.)
∂30-Dec-85 1247 REM%IMSSS.#Pup@SU-SCORE.ARPA Reader hacks, whitespace algorithm
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Dec 85 12:47:10 PST
Received: from IMSSS by Score with Pup; Mon 30 Dec 85 12:28:23-PST
Date: 29 Dec 1985 1717-PST
From: Rem@IMSSS
Subject: Reader hacks, whitespace algorithm
To: NGALL%BBNG.ARPA@SCORE
cc: COMMON-LISP%SU-AI@SCORE
It doesn't matter if your algorithm is inefficient, because it has
to be run only once per different character, after which the results
can be kept in a lookup table or as properties hanging off the character
objects. Therefore if the algorithm works at all, I think you have
solved the problem at hand, and since it's portable there's no urgency
to put your algorithm in the CLtL manual, the yellow pages will suffice.
<opinion of REM>
-------
∂02-Jan-86 1022 GSB@MC.LCS.MIT.EDU Re: Reader hacks
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Jan 86 10:21:48 PST
Date: Thu, 2 Jan 86 13:24:29 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: Re: Reader hacks
To: NGALL@BBNG.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
Message-ID: <[MC.LCS.MIT.EDU].770795.860102.GSB>
Date: 29 Dec 1985 18:21-EST
From: NGALL@BBNG.ARPA
I think there should be a function
SYNTAX-TYPE char => {ILLEGAL | WHITESPACE | CONSTITUENT |
SINGLE-ESCAPE | MULTIPLE-ESCAPE | MACRO}
Yes. Please. Don't forget terminating vs. non-terminating macro, and
keywords in the keyword package...
∂03-Jan-86 0050 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Re: Reader hacks
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Jan 86 00:49:50 PST
Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 3 Jan 86 03:47-EST
Date: Fri, 3 Jan 86 03:46 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Re: Reader hacks
To: GSB@MC.LCS.MIT.EDU, NGALL@BBNG.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-Reply-To: <[MC.LCS.MIT.EDU].770795.860102.GSB>
Message-ID: <860103034658.1.CFRY@DUANE.AI.MIT.EDU>
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 2 Jan 86 13:46-EST
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 2 Jan 86 13:48:16 EST
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Jan 86 10:21:48 PST
Date: Thu, 2 Jan 86 13:24:29 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: Re: Reader hacks
To: NGALL@BBNG.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
Message-ID: <[MC.LCS.MIT.EDU].770795.860102.GSB>
Date: 29 Dec 1985 18:21-EST
From: NGALL@BBNG.ARPA
I think there should be a function
SYNTAX-TYPE char => {ILLEGAL | WHITESPACE | CONSTITUENT |
SINGLE-ESCAPE | MULTIPLE-ESCAPE | MACRO}
Yes. Please. Don't forget terminating vs. non-terminating macro, and
keywords in the keyword package...
I hope you meant here that syntax types should be specified by symbols
in the keyword package, ie :illegal, :whitespace, etc.
∂03-Jan-86 0818 REM%IMSSS.#Pup@SU-SCORE.ARPA Reader hacks, whitespace algorithm
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Jan 86 08:17:59 PST
Received: from IMSSS by Score with Pup; Fri 3 Jan 86 08:14:41-PST
Date: 29 Dec 1985 1717-PST
From: Rem@IMSSS
Subject: Reader hacks, whitespace algorithm
To: NGALL%BBNG.ARPA@SCORE
cc: COMMON-LISP%SU-AI@SCORE
It doesn't matter if your algorithm is inefficient, because it has
to be run only once per different character, after which the results
can be kept in a lookup table or as properties hanging off the character
objects. Therefore if the algorithm works at all, I think you have
solved the problem at hand, and since it's portable there's no urgency
to put your algorithm in the CLtL manual, the yellow pages will suffice.
<opinion of REM>
-------
∂03-Jan-86 0917 LOOSEMORE@UTAH-20.ARPA yet another typo in the manual
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 3 Jan 86 09:17:31 PST
Date: Fri 3 Jan 86 10:16:31-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: yet another typo in the manual
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <12172321045.30.LOOSEMORE@UTAH-20.ARPA>
I haven't seen any mention of this one before: on page 133, the prog*
macro is referred to as a special form.
-Sandra
-------
∂04-Jan-86 1905 @SU-SCORE.ARPA:GSB@MC.LCS.MIT.EDU Reader hacks, whitespace algorithm
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Jan 86 19:05:23 PST
Received: from MC.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Sat 4 Jan 86 18:35:17-PST
Date: Sat, 4 Jan 86 14:51:14 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Sender: HENRIK@MC.LCS.MIT.EDU
Subject: Reader hacks, whitespace algorithm
To: "REM@IMSSS"@MC.LCS.MIT.EDU
cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA
Message-ID: <[MC.LCS.MIT.EDU].772855.860104.HENRIK>
Any caching scheme has to be integrated with the existing system
sufficiently so that the information gets uncached if anyone
changes character syntaxes.
∂05-Jan-86 1523 shebs%utah-orion@utah-cs.arpa Defsetf and define-setf-method
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 5 Jan 86 15:23:40 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA04498; Sun, 5 Jan 86 16:24:00 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA05598; Sun, 5 Jan 86 16:23:57 MST
Date: Sun, 5 Jan 86 16:23:57 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8601052323.AA05598@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Defsetf and define-setf-method
Recently I had a bright idea concerning the complex form of defsetf and
define-setf-method, namely that any defsetf could expand into an equivalent
call on define-setf-method, and that this would be the right thing for
complex defsetfs. Well, after a few days of screwing around with this,
I decided that I didn't really understand how a complex defsetf was
supposed to work, or what its full setf method should look like. Is it
all inherently hairy, or is there a simple relation between defsetf and
define-setf-method that this pea-brained implementor has failed to notice?
stan
∂06-Jan-86 0854 RAM@C.CS.CMU.EDU Another inconsistency in CLtL
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Jan 86 08:54:06 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 6 Jan 86 11:54:17-EST
Date: Mon, 6 Jan 1986 11:54 EST
Message-ID: <RAM.12173103405.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Another inconsistency in CLtL
In-reply-to: Msg of 27 Dec 1985 13:53-EST from SANDRA <LOOSEMORE at UTAH-20.ARPA>
I brought this up a couple months back, and I believe the
consensus was that all the functions that take package arguments will
accept a string or symbol as well, excepting the PACKAGE-xxx functions
which will only accept a package object. I doesn't say this anywhere
in the manual; this is a "clarification."
Rob
∂06-Jan-86 1323 Moon@SCRC-YUKON.ARPA Defsetf and define-setf-method
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 6 Jan 86 13:23:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 185039; Mon 6-Jan-86 16:18:08-EST
Date: Mon, 6 Jan 86 16:23 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Defsetf and define-setf-method
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8601052323.AA05598@utah-orion.ARPA>
Message-ID: <860106162308.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 5 Jan 86 16:23:57 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Recently I had a bright idea concerning the complex form of defsetf and
define-setf-method, namely that any defsetf could expand into an equivalent
call on define-setf-method, and that this would be the right thing for
complex defsetfs.
That is certainly a reasonable implementation technique and in fact is what I
believe most implementations do. Actually defsetf and define-setf-method
usually both expand into a third, internal thing.
Well, after a few days of screwing around with this,
I decided that I didn't really understand how a complex defsetf was
supposed to work, or what its full setf method should look like. Is it
all inherently hairy, or is there a simple relation between defsetf and
define-setf-method that this pea-brained implementor has failed to notice?
When you use define-setf-method you write a lot of calls to gensym, but when
you use defsetf the macro-expansion of defsetf takes care of making the gensyms
itself. See the discussion on page 103.
Here's an example (Guy, maybe this should go in the manual):
(defsetf subseq (sequence start &optional end) (new-sequence)
`(progn (replace ,sequence ,new-sequence
:start1 ,start :end1 ,end)
,new-sequence))
(define-setf-method subseq (sequence start &optional end)
(let ((seqtemp (gensym))
(startemp (gensym))
(endtemp (gensym))
(stotemp (gensym)))
(values (list seqtemp startemp endtemp)
(list sequence start end)
(list stotemp)
`(progn (replace ,seqtemp ,stotemp
:start1 ,startemp :end1 ,endtemp)
,stotemp)
`(subseq ,seqtemp ,startemp ,endtemp))))
∂07-Jan-86 0038 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Type questions
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 Jan 86 00:38:03 PST
Received: from JANIS.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 7 Jan 86 03:37-EST
Date: Tue, 7 Jan 86 03:38 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Type questions
To: common-lisp@SU-AI.ARPA
Message-ID: <860107033828.3.CFRY@JANIS.AI.MIT.EDU>
- What's the relationship between keyword, the type,
and keyword, a symbol in the keyword package?
Spicelisp calls the type keyword a subtype of symbol.
- is (subtype foo foo) true for any valid type foo ?
- Are the new types: signed-byte and unsigned-byte
subtypes of fixnum, like bit is?
- In Spicelisp, COMMON is a subtype of ATOM and
ATOM is a subtype of COMMON. True in CL?
CLtL should have explicite paragraphs and index entries
for every type. I noticed BIT and KEYWORD lacked this
kind of documentation.
∂07-Jan-86 0911 gls@THINK-AQUINAS.ARPA Type questions
Received: from THINK.COM by SU-AI.ARPA with TCP; 7 Jan 86 09:10:50 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Tue, 7 Jan 86 12:10:49 est
Date: Tue, 7 Jan 86 12:11 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Type questions
To: cfry@OZ.AI.MIT.EDU, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860107033828.3.CFRY@JANIS.AI.MIT.EDU>
Message-Id: <860107121140.2.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Tue, 7 Jan 86 03:38 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
- What's the relationship between keyword, the type,
and keyword, a symbol in the keyword package?
Spicelisp calls the type keyword a subtype of symbol.
They are the same notion. An item of type keyword is a symbol in the
keyword package.
- is (subtype foo foo) true for any valid type foo ?
The book does not require this right now; SUBTYPEP is permitted to throw
up its hands and say "I don't know". The nature of SUBTYPEP and what cases
it is required to handle ought to be tied down more.
- Are the new types: signed-byte and unsigned-byte
subtypes of fixnum, like bit is?
Yes. The descriptions of these types on pages 48-49 explicitly describe
them as being equivalent to specified subtypes of integer (type specifiers
of the form (INTEGER x y)).
- In Spicelisp, COMMON is a subtype of ATOM and
ATOM is a subtype of COMMON. True in CL?
How can COMMON be a subtype of ATOM? CONS must be a subtype of COMMON,
so if COMMON is a subtype of ATOM then CONS must be a subtype of ATOM.
But no cons can be an ATOM (by the definition of ATOM), so if CONS is
a subtype of ATOM then CONS must be an empty type. Therefore if COMMON
is a subtype of ATOM there are no conses.
CLtL should have explicite paragraphs and index entries
for every type. I noticed BIT and KEYWORD lacked this
kind of documentation.
See my next message.
∂07-Jan-86 0913 gls@THINK-AQUINAS.ARPA No more index typos, please
Received: from THINK.COM by SU-AI.ARPA with TCP; 7 Jan 86 09:12:57 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Tue, 7 Jan 86 12:12:56 est
Date: Tue, 7 Jan 86 12:13 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: No more index typos, please
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860107121347.3.GLS@THINK-JEHOSEPHAT.ARPA>
I would like to ask that no more messages be sent to me about erroneous
or missing index entries in CLtL. I am aware that the index is dreadful
and that many important entries are missing. I have plans to do a much
more thorough job on the next edition of the book by starting from
scratch, so incremental corrections to the existing idnex are not useful
to me at this time. Thanks to everyone who has pointed out errors in
the past.
--Guy
∂08-Jan-86 0839 kempf@hplabsc Hooks for Common Objects
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 8 Jan 86 08:38:25 PST
Received: from hplabsc by hplabs.ARPA ; Wed, 8 Jan 86 08:37:10 pst
Received: by hplabsc (4.16/4.30) ;
id AA03359; Wed, 8 Jan 86 08:37:59 pst
Date: Wed, 8 Jan 86 08:37:59 pst
From: Jim Kempf <kempf@hplabsc>
Message-Id: <8601081637.AA03359@hplabsc>
To: common-lisp@su-ai.ARPA
Subject: Hooks for Common Objects
(Please ignore if this posting is repeated, we're having some
trouble with our mailer daemon)
At the December Common Lisp meeting in Boston, Alan Snyder
presented a list of proposed language changes which we
felt were needed in order to implement CommonObjects. For
the benefit of those who weren't at the meeting, here
is a quick summary of the changes (with notations for
changes which are also part of Guy Steele's list):
1) Change DEFSTRUCT in the following ways, to better support
encapsulation:
a) Specify that the underlying data structure for DEFSTRUCT's is
a vector-like object to which user access is
made difficult,
b) Add a keyword argument specifying that no accessor
functions be generated. Access to slots would then
only be through the accessor functions for the underlying
data structure,
c) Require that the type predicate, if specified, be used
by TYPEP,
d) Allow DEFSTRUCT to take function names for functions to
be used when two DEFSTRUCT's are compared using EQL, EQUAL,
and EQUALP.
2) Change the type system in the following ways:
a) Introduce a new predicate, TYPE-DEFINED-P, which takes a
symbol and returns T if a type with that name is defined,
b) Introduce a new function, UNDEFINE-TYPE, which takes a
symbol and undefines the type, if it is defined. This is
similar to Steele's proposal for undo functions,
c) Introduce a new function, RENAME-TYPE, which takes two
symbols, and renames the type known as the first to the
second.
3) Introduction of a new special form, LET-PSEUDO, which allows
the definition of lexical instance variables (might also be
useful for Smalltalk and Flavors instance variable access).
4) Clarify the role of #, so that load-time execution of embedded forms
is possible from compiled, as well as interpreted code.
5) Introduce the following optimization hooks:
a) Allow the environment parameter to DEFMACRO to be queried for various
information which would make optimization more portable. This is similar
to Steele's proposal for PARSE-BODY, except DECLARE forms from the
environment as well as the body would need to be returned,
b) Allow a macro to be associated with a function name for compilation
purposes. Most implementations will do this in a nonportably anyway,
if only to allow arithmetic operations to be optimized,
c) Add two functions, which facilitate the efficient definition of
indirect function calls.
6) Introduce the following hooks for seperate compilation:
a) Allow a macro to inquire on its &ENVIRONMENT parameter if the result
will be used in a file compilation,
b) Provide a hash table for each COMPILE-FILE where information associated
with the compilation can be stored.
People who are interested in more details can ask for the document outlining
the hooks:
A Common Objects Implementation Kernel, by Alan Snyder, Michael Creech,
and James Kempf, STL-TM-85-14
Electronic addresses are SNYDER@HPLABS or KEMPF@HPLABS. Mail address is:
Hewlett-Packard Labs
1501 Page Mill Rd.
Palo Alto, CA
94304
The most critical of the above hooks is 6). Currently, COMPILE-FILE is not
defined to change its environment in any way which would allow one to
know that a file is being compiled. This has many (mostly unpleasent)
consequences for bootstrapping and type definition, and we currently
use a nonportable technique which catches about 98% of the problems.
We would be interested in other people's experiences with seperate
compilation. How does one handle problems with compiling type/flavor/class
defintions which are part of the compiler, for example? Would the above
mentioned changes simplify things, or is there some way within the
current language standard that seperate compilation can be done
safely and portably?
Jim Kempf kempf@hplabs
∂09-Jan-86 0847 gls@THINK-AQUINAS.ARPA Common Lisp 'open'
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 9 Jan 86 08:33:10 PST
Received: from eligius by GODOT.THINK.COM via CHAOS; Thu, 9 Jan 86 10:44:07 est
Date: Thu, 9 Jan 86 10:45 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Common Lisp 'open'
To: massar@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 8 Jan 86 20:13-EST from JP Massar <massar>
Message-Id: <860109104511.2.GLS@THINK-ELIGIUS.ARPA>
Date: Wed, 8 Jan 86 20:13:29 est
From: massar (JP Massar)
Suppose I have the following:
(open "x" :direction :output :if-exists :append :if-does-not-exist :create)
This is fine and dandy unless I don't have permission to write to the file
and/or create a new file. Probing the file is of no use, since either the
file is there and it tells me so or it isn't and it tells me so -- in
either case I still want to execute the open.
It seems like a generic :if-unable-to <retval> construct would be a good
idea.
As it is I can see no way or writing robust, portable code that deals with
files. I realize that "The opening if files is an area where complete
portability is too much to hope for", but this seems like a pretty general
problem (even on a Lispm, I could probe a file, then have the Chaosnet
go down, and have the open fail on me...).
Any ideas? Helpful hints?
What we really need is a Common Lisp error-handling system.
However, I am forwarding this to the Common Lisp mailing list.
--Guy
∂09-Jan-86 1910 LOOSEMORE@UTAH-20.ARPA questions about packages
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 9 Jan 86 19:09:12 PST
Date: Thu 9 Jan 86 20:08:03-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: questions about packages
To: common-lisp@SU-AI.ARPA
Message-ID: <12174001594.14.LOOSEMORE@UTAH-20.ARPA>
1. Can a package use itself? Or is this "an error"?
2. Does the :use argument to in-package default to the list of the
lisp package in the same way that it does for make-package? In
other words, if you do (in-package 'foo) and package foo does not
yet exist, does it default to using the lisp package? What if
package foo does exist but doesn't already use the lisp package?
-Sandra
-------
∂10-Jan-86 0711 NGALL@G.BBN.COM Re: questions about packages
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 10 Jan 86 07:11:21 PST
Date: 10 Jan 1986 09:52-EST
Sender: NGALL@G.BBN.COM
Subject: Re: questions about packages
From: NGALL@G.BBN.COM
To: LOOSEMORE@UTAH-20.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]10-Jan-86 09:52:42.NGALL>
In-Reply-To: <12174001594.14.LOOSEMORE@UTAH-20.ARPA>
Date: Thu 9 Jan 86 20:08:03-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: questions about packages
Message-ID: <12174001594.14.LOOSEMORE@UTAH-20.ARPA>
1. Can a package use itself? Or is this "an error"?
Yes. A package can use itself (though an error may be signalled due to name
conflicts).
2. Does the :use argument to in-package default to the list of the
lisp package in the same way that it does for make-package? In
other words, if you do (in-package 'foo) and package foo does not
yet exist, does it default to using the lisp package? What if
package foo does exist but doesn't already use the lisp package?
Hmmm...Good Question. "This function is similar to MAKE-PACKAGE" should be
made more explicit. I think the intent here is that if :USE was
actually an argument to IN-PACKAGE it is merely passed on to the call
to MAKE-PACKAGE (in the case of FOO not existing); if it wasn't an
actual arg. to IN-PACKAGE, MAKE-PACKAGE is called with no :USE arg.
(and hence :USE defaults to '(LISP)). In the case where FOO existed,
if :USE is not an actual arg. to IN-PACKAGE, :USE defaults to '().
-- Nick
∂10-Jan-86 0941 RPG Varia from Tektronix
To: common-lisp@SU-AI.ARPA
I am forwarding this for Will Clinger at Tektronix:
With regard to the proposed starred change to page 145 of CLtL:
(*) 145 ....Similarly, a function that takes a &REST argument
should not destroy it because its top-level list structure might
share with a list that the user gave as the last argument to
APPLY.
This would imply that destructive operations on any list given as the
last argument to APPLY are also forbidden unless it is known that the
function being applied does not take a &REST argument. The following
code, for example, would be in error:
(defun baz (&rest x)
(if (numberp (car x))
#'(lambda () (1+ (car x)))
#'(lambda () 0)))
(defun kablooey ()
(let* ((zog (list 3))
(bar (apply #'baz zog)))
(setf (car zog) 'zag)
(funcall bar)))
;;; William Clinger
;;; willc%tekchips@tektronix.csnet
;;; Tektronix Computer Research Laboratory
∂10-Jan-86 1102 GJC@MC.LCS.MIT.EDU SETF of an &REST list.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Jan 86 11:02:22 PST
Date: Fri, 10 Jan 86 14:01:04 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: SETF of an &REST list.
To: RPG@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 10 Jan 86 0941 PST from Dick Gabriel <RPG at SU-AI.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].779630.860110.GJC>
What you have to say is that SETF on the &REST list is not portable.
e.g.
(defun foo (&rest l) (setf (car l) 'foo))
(defun test ()
(let ((x (list nil)))
(apply 'foo x)
(car x)))
In NIL (or Maclisp for that matter): (test) ==> NIL
In zetalisp its always been that: (test) ==> FOO.
This is also the kind of behavior that may be different depending
on if a function is interpreted or compiled or traced etc.
∂12-Jan-86 0642 RAM@C.CS.CMU.EDU fill-pointers and destructive sequence functions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jan 86 06:42:04 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 12 Jan 86 09:42:21-EST
Date: Sun, 12 Jan 1986 09:42 EST
Message-ID: <RAM.12174652267.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: fill-pointers and destructive sequence functions
If a destructive sequence function such as DELETE is passed an
array with a fill pointer, may it reduce the size of the argument by
adjusting the fill-pointer? The alternative would be to require the
(ARRAY-DIMENSION <res> 0) to be the resulting length. This seems
excessively restrictive, since sequence functions only deal with the
active elements of vectors.
What should ADJUST-ARRAY do with the fill-pointer in an array if
there is no :FILL-POINTER argument specified? It seems sub-optimal to
leave it pointing into hyperspace. Does the fill pointer go away?
Is it legal for MAKE-ARRAY to return an array with a fill-pointer
when no :FILL-POINTER option was specified? This question is similar
to the question "Are there contexts in which not having a fill-pointer
is important?" Currently any Spice Lisp vector which is not a
SIMPLE-ARRAY has a fill pointer.
Rob
∂13-Jan-86 1711 LOOSEMORE@UTAH-20.ARPA time of evaluation
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 13 Jan 86 17:10:05 PST
Date: Mon 13 Jan 86 18:08:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: time of evaluation
To: common-lisp@SU-AI.ARPA
Message-ID: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>
Should types defined via deftype and defstruct be entered into the type
structure at compile time as well as load/eval time? It seems pretty
useless to declare things to be of a structure type if the compiler
doesn't recognize the structure name as a valid type specifier. The
documentation for deftype/defstruct says nothing special about things
happening at compiletime, though, so I assume the usual defaults apply
and nothing happens until loadtime unless you wrap an eval-when around
it. Seems kind of awkward.
Along similar lines, I assume one has to wrap an eval-when around
defstructs if one wishes to use #s syntax later on in the file to
create a constant structure, so that the constructor function required
for reading in the constant will be defined at compiletime.
-Sandra
-------
∂14-Jan-86 1217 @MC.LCS.MIT.EDU:Soley@MC.LCS.MIT.EDU time of evaluation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 14 Jan 86 12:17:11 PST
Received: from CHERRY.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JAN 86 15:17:47 EST
Date: Tue, 14 Jan 86 15:17 EST
From: Soley@MIT-MC.ARPA
Subject: time of evaluation
To: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860114151755.6.SOLEY@MIT-CHERRY.ARPA>
Date: Mon 13 Jan 86 18:08:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: time of evaluation
To: common-lisp@SU-AI.ARPA
Message-ID: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>
Should types defined via deftype and defstruct be entered into the type
structure at compile time as well as load/eval time?
Definitely yes. Although the book may not say so, it would be pretty
bad for the compiler to not recognize (and perhaps open-code accessors
of) a type previously defined in the same file.
Along similar lines, I assume one has to wrap an eval-when around
defstructs if one wishes to use #s syntax later on in the file to
create a constant structure, so that the constructor function required
for reading in the constant will be defined at compiletime.
I think DEFSTRUCT should be "implicitly" eval-when (eval compile load),
for the same reasons as above. This is what Gold Hill GCLisp and others
do, for example.
-- Richard Soley
∂14-Jan-86 1854 sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Errata on p.431
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 14 Jan 86 18:54:07 PST
Received: from tektronix by csnet-relay.csnet id ah00838; 14 Jan 86 21:43 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Received: from tekchips by tektronix with smtp ; 14 Jan 86 13:08:36 PST
Date: Tuesday, 14 Jan 86 12:54:57 PST
Subject: Errata on p.431
There are two mistakes in the first example on p.431.
The function cerror in both places has an argument vals missing.
In the first half of the example:
(cerror "Assume .............
.....................
but ~R ~:[were~;was~] supplied."
nvals (= nvals 1))
The last 2 args should be replaced by the three args:
vals nvals (= nvals 1)
Similarly in the second cerror function, after the line
but ~R were supplied."
the line
nvals)
should be replaced by
vals nvals)
--sridhar
∂15-Jan-86 0606 BSG@SCRC-STONY-BROOK.ARPA time of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86 06:05:55 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 392860; Wed 15-Jan-86 09:06:01-EST
Date: Wed, 15 Jan 86 09:11 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: time of evaluation
To: Soley@MIT-MC.ARPA, LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860114151755.6.SOLEY@MIT-CHERRY.ARPA>
Message-ID: <860115091150.4.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Tue, 14 Jan 86 15:17 EST
From: Soley@MIT-MC.ARPA
Date: Mon 13 Jan 86 18:08:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: time of evaluation
To: common-lisp@SU-AI.ARPA
Message-ID: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>
Should types defined via deftype and defstruct be entered into the type
structure at compile time as well as load/eval time?
Definitely yes. Although the book may not say so, it would be pretty
bad for the compiler to not recognize (and perhaps open-code accessors
of) a type previously defined in the same file.
Along similar lines, I assume one has to wrap an eval-when around
defstructs if one wishes to use #s syntax later on in the file to
create a constant structure, so that the constructor function required
for reading in the constant will be defined at compiletime.
I think DEFSTRUCT should be "implicitly" eval-when (eval compile load),
for the same reasons as above. This is what Gold Hill GCLisp and others
do, for example.
-- Richard Soley
This is completely unclear. Consider an incompatible change to a defstruct
used by the compiler. Consider that one of the accessor functions is passed
as a funarg by the compiler. Doing this would break the compiler. It has
to do something a lot more subtle, that limits its effects to functions being
compiled in the same file.
∂15-Jan-86 0815 SOLEY@MC.LCS.MIT.EDU time of evaluation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Jan 86 08:15:08 PST
Date: Wed, 15 Jan 86 11:16:02 EST
From: Richard Mark Soley <SOLEY@MC.LCS.MIT.EDU>
Subject: time of evaluation
To: BSG@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, LOOSEMORE@UTAH-20.ARPA
In-reply-to: Msg of Wed 15 Jan 86 09:11 EST from Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].784707.860115.SOLEY>
Date: Wed, 15 Jan 86 09:11 EST
From: Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>
To: Soley at MIT-MC.ARPA, LOOSEMORE at UTAH-20.ARPA,
common-lisp at SU-AI.ARPA
Re: time of evaluation
Date: Tue, 14 Jan 86 15:17 EST
From: Soley@MIT-MC.ARPA
Date: Mon 13 Jan 86 18:08:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: time of evaluation
To: common-lisp@SU-AI.ARPA
Message-ID: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>
Should types defined via deftype and defstruct be entered into the type
structure at compile time as well as load/eval time?
This is completely unclear. Consider an incompatible change
to a defstruct used by the compiler. Consider that one of
the accessor functions is passed as a funarg by the compiler.
Doing this would break the compiler. It has to do something
a lot more subtle, that limits its effects to functions being
compiled in the same file.
I had this exact problem with the GCLisp compiler, as a matter of fact.
HOWEVER, I think the language should be designed more for the user
than the compiler writer, who we assume has more smarts.
-- Richard
∂15-Jan-86 0858 DLW@SCRC-STONY-BROOK.ARPA time of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86 08:58:50 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 393039; Wed 15-Jan-86 11:58:41-EST
Date: Wed, 15 Jan 86 11:58 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: time of evaluation
To: BSG@SCRC-STONY-BROOK.ARPA, Soley@MIT-MC.ARPA, LOOSEMORE@UTAH-20.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: <860115091150.4.BSG@CONCORD.SCRC.Symbolics.COM>
Message-ID: <860115115858.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 15 Jan 86 09:11 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
This is completely unclear. Consider an incompatible change to a defstruct
used by the compiler.
(Are you aware that defstruct is implicitly "(compile load eval)" in our
implementation, and always has been?)
The real issue here is what it means to "compile from a file". It's a
tricky issue when the Lisp environment that's running the compiler is
not a special Lisp created only for that compilation and then discarded
(the way we used to do it in Maclisp), but is an ongoing environment.
When the compiler sees a "defmacro" early in a file, it ideally should
not actually alter the Lisp environment at all, but it should let forms
in the file use that macro. It needs to maintain a "subjunctive Lisp
environment", in which the contract of the compiler, given a Lisp
fucntion to compile, is to produce code that will do the same thing that
the interpreted code would do if that interpreted code were run in the
"subjunctive environment", which means "if all the previous stuff file,
but not the subsequent stuff, had been evaluated".
The Symbolics implementation really does maintain a "subjunctive
environment" for macros. But it doesn't do a perfect job. Consider a
file with the following forms:
(defun util (x) (list x x))
(defmacro mac (y) (util y))
(defun test (z) (mac z))
Now, if you call compile-file on this file, your Lisp environment should
not end up having "util" defined when you are done. Yet, "util" needs
to be in the "subjunctive environment", so that when the compiler tries
to compile "mac", it will be able to. Our implementation of
compile-file signals "The function UTIL is not defined." I'd be interested
to know if any implementation handles this correctly.
The current practice is that the programmer has to get around this by
inserting an eval-when around the definition of util (or put it into a
"defs" file that gets loaded before compilation, which is really the
same thing). The problem is that it conflicts with/overrides the
definition of "util" in the running environment.
This is essentially the same problem as the one you are pointing out, in
the "defstruct that's part of the compiler" example, except that
breaking the compiler is obviously a more serious thing that will lead
to immediate worse problems. Richard is right about how users don't
hack the compiler much, but it's still true that using (eval-when
(compile ...) ...) breaks the principle that compile-file should leaves
the state of the Lisp environment unchanged, and user programs can
definitely suffer from this problem: you compile a new version, and the
suddently the old version doesn't work any more, perhaps because you
modified some function like util.
∂15-Jan-86 1002 kempf@hplabsc Re: time of evaluation
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 15 Jan 86 09:55:14 PST
Received: from hplabsc by hplabs.ARPA ; Wed, 15 Jan 86 09:53:25 pst
Received: by hplabsc (4.16/4.30) ;
id AA07687; Wed, 15 Jan 86 09:54:28 pst
Date: Wed, 15 Jan 86 09:54:28 pst
From: Jim Kempf <kempf@hplabsc>
Message-Id: <8601151754.AA07687@hplabsc>
To: BSG@SCRC-STONY-BROOK.ARPA, DLW@SCRC-QUABBIN.ARPA, LOOSEMORE@UTAH-20.ARPA,
Soley@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
Subject: Re: time of evaluation
Cc: snyder@hplabsc
This discussion is interesting, in that, it parallels some of
our thinking on modifications to the compile time environment
to support CommonObjects object oriented programming. A
proposed addition to Common Lisp which we have suggested
is a compiler dictionary (essentially, a hash table) which
gets created during file compilation and into which defstructs
and define-types (which create CommonObjects types) can enter
information which needs to be discarded after the file is
compiled. The problems with "really" defining a type or
defstruct at compile time not only have to do with the
compiler but also with the environment in general. Consider
development in an environment which uses types or defstructs
in its implementation. If changes are made to the types or
defstructs, one doesn't want those changes to be propogated
to the environment during the debugging and development
phase, otherwise the entire environment may fall apart.
Our current version of CommonObjects uses a highly implementation
dependent way of getting around these problems, which works
about 99% of the time. It is inherently not portable, however,
because it depends on being able to tell when a file is
being compiled, and, according to the definition of compile-file,
this information is not made available. A similar problem occurs
with defstruct.
Jim Kempf kempf@hplabs
∂15-Jan-86 1049 FAHLMAN@C.CS.CMU.EDU time of evaluation
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86 10:49:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Jan 86 12:57:17-EST
Date: Wed, 15 Jan 1986 12:57 EST
Message-ID: <FAHLMAN.12175474181.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: time of evaluation
In-reply-to: Msg of 15 Jan 1986 12:54-EST from Jim Kempf <kempf at hplabsc>
I agree pretty much with Weinreb's analysis of the problem. It seems to
me that defstructs and deftypes should be handled the same way macros
are when compiling a file. In older Lisps of the Maclisp generation, I
think that it was always the case that such things were simply evaluated
in the Lisp in which the compiler is running, altering that environment
permanently. This didn't bother people too much, since typically you
fired up a special Lisp/Compiler job that was only used for compiling
one or more files. I think that this scheme is permitted in Common
Lisp, but I haven't gone back to check the fine print; I'm sure that
many implementations do it this way.
In newer Lisps, people would like to be able to call Compile-File, have
the compiler do its thing on one or more files, and then go on to do
other things in that Lisp. The process of compiling one or more files
should ideally not have any permanent effects on the Lisp in which
Compile-File is called. One way to do this is to have Compile-File
spawn a separate Lisp process to do the compilation(s) in, perhaps a
virgin Lisp or perhaps a clone of the calling Lisp. (Which is
preferable? Should a file being compiled be able to depend on macros
that happen to be defined in the calling Lisp?)
That solution is not attractive in systems like the Lisp Machine, where
there is only one big Lisp address space and where people like to live
in that for days or weeks on end without polluting it. Such systems do
indeed need to create some sort of quarantined environment within their
single Lisp. One suggestion made some time ago was that when a file did
not specify any particular package, it should not be compiled in the
calling Lisp's current package, but rather in
SPECIAL-COMPILER-TEMPORARY-PACKAGE. The thing that dumps out the FASL
file (or whatever) would arrange that symbols interned in this specific
package would be loaded into whatever package is current when the FASL
file is read in. On the other hand, if the file specifies package FOO,
you read the stuff into package FOO. It seems to me that this would
solve the problem in many cases, since if the user defined a macro,
structure-name, or type name, the symbol naming that thing would be
quarantined. However, you still could get conflicts in some odd cases,
or when the user compiles a file with a specified package from a Lisp
that has that package loaded.
-- Scott
∂15-Jan-86 1226 RAM@C.CS.CMU.EDU time of evaluation
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86 12:25:55 PST
Received: ID <RAM@C.CS.CMU.EDU>; Wed 15 Jan 86 14:32:25-EST
Date: Wed, 15 Jan 1986 14:32 EST
Message-ID: <RAM.12175491458.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: BSG@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA,
LOOSEMORE@UTAH-20.ARPA, Soley@MIT-MC.ARPA
Subject: time of evaluation
I think it's a bad idea to make defstruct literally
eval-when (compile load eval). It will cause you (the implementor) no
end of grief even if it doesn't bother users much. In Spice Lisp, our
current solution is to have two separate defstruct definition
properties, DEFSTRUCT-DEFINITION and DEFSTRUCT-DEFINITION-IN-COMPILER.
The -IN-COMPILER property is set when the defstruct is compiled, and
the normal definition is set at load time. The compiler definition is
used preferentially for purposes of inclusion and any compiler uses.
Compiling a defstruct puts compiler information into the
environment so that accessors and predicates are open-coded, but the
actual function definitions are not put into the environment. One
problem with a strict eval-when compile strategy is that it causes any
accessors in the environment to be clobbered with interpreted
definitions. We also had problems with compiling the file which
defines streams breaking the type structure such that *TERMINAL-IO*
was no longer a stream, with understandably serious consequences.
I'm sure that there are lots of problems with this approach, both
in particular and in general, since it is similar to the defmacro
problem but more complicated due to the more complicated semantics of
defstruct. Nonetheless, I think that an approach like this is
expedient for the same reasons that make special-casing macros
important.
Rob
∂15-Jan-86 1430 LOOSEMORE@UTAH-20.ARPA Re: time of evaluation
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 15 Jan 86 14:30:04 PST
Date: Wed 15 Jan 86 15:27:01-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: time of evaluation
To: RAM@C.CS.CMU.EDU
cc: DLW@SCRC-QUABBIN.ARPA, BSG@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA,
Soley@MIT-MC.ARPA
In-Reply-To: <RAM.12175491458.BABYL@C.CS.CMU.EDU>
Message-ID: <12175523298.9.LOOSEMORE@UTAH-20.ARPA>
This sounds similar to what currently happens with DEFSTRUCT in PCLS --
the information needed to open-code accessors and for handling :include
gets added at both compile and load time, but the functions defstruct
generates are only defined a load time. I think that, to be consistent,
it would probably be better if the functions were defined at compile
time too. After all, if you've just overwritten part of the information
for an existing structure type, you might as well overwrite the rest of
it too, and then at least the two pieces of information will agree with
each other.
The reason why I brought this up in the first place is that it's very
difficult to write macros portably without knowing what things become
part of the compile-time environment and what things don't. I suppose
one could take the conservative approach and wrap an
(eval-when (eval compile load) ...) around the entire contents of
each file, but somehow I don't think this is what the language
designers really had in mind. I don't have particularly strong feelings
myself on what things should happen when, or whether things defined
in the context of the compiler should or shouldn't modify the
environment permanently. I would rather see some agreement now on a
standard that most implementations already do, or can easily be changed
to do, rather than spend 3 years arguing about what the most elegant
solution is, and then another 3 years while everybody figures out how
to implement it....
-Sandra
-------
∂15-Jan-86 1445 DLW@SCRC-STONY-BROOK.ARPA time of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86 14:45:28 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 393440; Wed 15-Jan-86 17:45:29-EST
Date: Wed, 15 Jan 86 17:45 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: time of evaluation
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12175474181.BABYL@C.CS.CMU.EDU>
Message-ID: <860115174547.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
In what Lisp environment is compile-file defined to compile the file?
There are two possibilities: (1) it should use the present Lisp
environment; (2) it should use an empty initial Lisp environment. CLtL
doesn't say, but it needs to, because the two are significantly
semantically different.
If (1), then the techniques of spawning a separate Lisp process, or
using a new package, won't work, unless you try to cleverly copy state
from one place another or something. If (2), then you can't break your
program into a "defs" file that defines a bunch of macros, which you
then load before you compile other files. It means that every time you
do a compile-file, you start with a bare Lisp and have to load up all
the files with all the macros and other things that you plan to use.
Even if you're compiling twenty files in a row and they all use the same
defs files, you have to load the defs files over and over again. This
kind of "batch" operation is highly undesirable.
∂15-Jan-86 1457 RAM@C.CS.CMU.EDU time of evaluation
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86 14:56:28 PST
Received: ID <RAM@C.CS.CMU.EDU>; Wed 15 Jan 86 17:55:22-EST
Date: Wed, 15 Jan 1986 17:55 EST
Message-ID: <RAM.12175528440.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: BSG@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA, DLW@SCRC-QUABBIN.ARPA,
Soley@MIT-MC.ARPA
Subject: time of evaluation
In-reply-to: Msg of 15 Jan 1986 17:27-EST from SANDRA <LOOSEMORE at UTAH-20.ARPA>
I agree it would be most consistent to evaluate everything all the
time, but as JAR pointed out a while back, consistency is not an
attribute of the Common Lisp language. In this case, I think it is
better to be inconsistent so that you aren't consistently screwed.
One thing to consider is that when you make a thing implicitly
eval-when compile, there is no way to override this behavior. In
contrast, it is always possible to make something evaluated in the
compiler by using eval-when (compile). At least, that is my
interpretation of eval-when's semantics, which are rather poorly
defined, as I have mentioned before.
Rob
∂15-Jan-86 1504 Moon@SCRC-STONY-BROOK.ARPA time of evaluation of defstruct, deftype, etc.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86 15:04:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 393466; Wed 15-Jan-86 18:00:48-EST
Date: Wed, 15 Jan 86 18:01 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: time of evaluation of defstruct, deftype, etc.
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12175474181.BABYL@C.CS.CMU.EDU>
Message-ID: <860115180103.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
This problem cannot be solved with multiple address spaces, unless you have a
very complicated mechanism for sharing objects between address spaces, and
cannot be solved with packages, because packages provide partial sharing and
partial isolation with the division between sharing and isolation not being the
same division that you need to distinguish the Lisp world in which you are
running the compiler from the Lisp world that will exist when the compiler's
output is loaded.
A more viable technique is to attack the problem not at the level of binding
objects to addresses, and not at the level of binding strings to symbols, but
at the level of binding names to objects. Many compilers already do this for
macros, using one mechanism for binding the name of a macro to its definition
when DEFMACRO is loaded, or evaluated interactively, and a second mechanism
when DEFMACRO is compiled. It isn't difficult to extend this to other name
bindings, such as binding a structure name to the internal description of the
structure. I'm sure we can all design data representations for doing this.
The main issue in implementing this is getting each place that looks up a name,
looking for an object, to know which mechanism it is supposed to be using. In
some cases the lexical environment Common Lisp passes to macros is an
appropriate place to store this information. I could say more, and so could
other implementors, but I don't want to bore you.
Stepping back a level, the main issue for the Common Lisp community is do
we want to say that this is an issue which each implementation should solve
for itself, in order to have a compiler that can be considered "high quality",
or is this something that should be made a standard part of the language,
with a portable interface? Obviously one alternative is "better" for the
users and the other alternative is less work for the language standardization
effort.
∂15-Jan-86 1728 FAHLMAN@C.CS.CMU.EDU time of evaluation
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86 17:27:56 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Jan 86 20:27:31-EST
Date: Wed, 15 Jan 1986 20:27 EST
Message-ID: <FAHLMAN.12175556144.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: time of evaluation
In-reply-to: Msg of 15 Jan 1986 17:45-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
In what Lisp environment is compile-file defined to compile the file?
There are two possibilities: (1) it should use the present Lisp
environment; (2) it should use an empty initial Lisp environment. CLtL
doesn't say, but it needs to, because the two are significantly
semantically different.
I agree that it would be worthwhile to nail this down.
If (1), then the techniques of spawning a separate Lisp process, or
using a new package, won't work, unless you try to cleverly copy state
from one place another or something. If (2), then you can't break your
program into a "defs" file that defines a bunch of macros, which you
then load before you compile other files. It means that every time you
do a compile-file, you start with a bare Lisp and have to load up all
the files with all the macros and other things that you plan to use.
Even if you're compiling twenty files in a row and they all use the same
defs files, you have to load the defs files over and over again. This
kind of "batch" operation is highly undesirable.
Your objection to interpretation 1 depends totally on what sort of
system you're thinking about. On Unix, you can create a clone of the
current process with a simple fork. Then if you're the new copy, you do
the compile and commit suicide. Nothing clever required.
Your objection to 2 also depends on the assumptions you are making about
the system environment. In the previous message, I was careful to say
"when you compile ONE OR MORE files". If you spawn a virgin Lisp
process in which to compile, you just tell it to compile all 20 files
(including some defs files) in a lump, preserving state between
compiles; then commit suicide. Or you could keep the compiler process
and its associated state around indefinitely and give the user a
REVIRGINIZE-COMPILER call which kills off the now-polluted compiler
process and creates a new fresh one.
On the 3600, either of these solutions presents a problem, I guess.
Since there's only one huge Lisp process (address space) to play with,
and since it is very expensive to save a copy of this huge thing on
disk, you don't have the option of compiling in one copy of an address
space while running in a second copy that is not polluted by the
compile. The right solution is to catch up with Unix and other modern
operating systems by putting in true multiple processes (sorry, couldn't
resist), but if that is not possible, I guess this business of stashing
the compiler's state changes in funny undoable places is about the best
you can do. I wouldn't like to see this solution cast in concrete for
everyone, though.
-- Scott
∂15-Jan-86 1736 FAHLMAN@C.CS.CMU.EDU time of evaluation of defstruct, deftype, etc.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86 17:36:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Jan 86 20:35:54-EST
Date: Wed, 15 Jan 1986 20:35 EST
Message-ID: <FAHLMAN.12175557655.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: time of evaluation of defstruct, deftype, etc.
In-reply-to: Msg of 15 Jan 1986 18:01-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
This problem cannot be solved with multiple address spaces, unless you have a
very complicated mechanism for sharing objects between address spaces,
I don't understand this. What has to be shared in a complicated way?
Stepping back a level, the main issue for the Common Lisp community is do
we want to say that this is an issue which each implementation should solve
for itself, in order to have a compiler that can be considered "high quality",
or is this something that should be made a standard part of the language,
with a portable interface? Obviously one alternative is "better" for the
users and the other alternative is less work for the language standardization
effort.
As I said in my answer to Weinreb, the way you want to go about solving
this problem depends a lot on the kind of system you're running in. In
Accent, for example, there are multiple processes and it is very quick
and easy to create a clone process due to the copy-on-write memory
management. We should probably standardize those things that we have to
in order to have sets of portable source files that can be compiled and
run anywhere, and leave to the local culture those things that are not
required for this.
-- Scott
∂15-Jan-86 1850 Moon@SCRC-STONY-BROOK.ARPA time of evaluation of defstruct, deftype, etc.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86 18:50:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 393624; Wed 15-Jan-86 21:50:12-EST
Date: Wed, 15 Jan 86 21:50 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: time of evaluation of defstruct, deftype, etc.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12175557655.BABYL@C.CS.CMU.EDU>
Message-ID: <860115215029.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Jan 1986 20:35 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
This problem cannot be solved with multiple address spaces, unless you have a
very complicated mechanism for sharing objects between address spaces,
I don't understand this. What has to be shared in a complicated way?
Copy-on-write is fine for getting things to the compiler, but what if you want to
get something back?
I don't want to get into a long discussion of this.
Stepping back a level, the main issue for the Common Lisp community is do
we want to say that this is an issue which each implementation should solve
for itself, in order to have a compiler that can be considered "high quality",
or is this something that should be made a standard part of the language,
with a portable interface? Obviously one alternative is "better" for the
users and the other alternative is less work for the language standardization
effort.
As I said in my answer to Weinreb, the way you want to go about solving
this problem depends a lot on the kind of system you're running in.
So your position is that this should not be made a standard part of the language.
OK.
∂16-Jan-86 0141 REM@IMSSS 2 ways to compile macros correctly
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-16 01:39:30 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1986 January 16 01:37:21 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS> (this host known locally only)
To:COMMON-LISP@SU-AI
Subject:2 ways to compile macros correctly
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA
From the discussion, it seems there are two major ways to implement
isolation of the compiler environment from the week-old running
environment so that the compiler doesn't side-effect the running
environment (assuming your operating system doesn't allow you to
simply create a second virtual machine identical to the original but
with copy-on-write):
(1) You can implement copy-on-write at the LISP level, if you have
tree-structured packages or can fake the same out by long names of packages.
(2) You can install all compiler side-effects as unusual properties
instead of the usual properties.
To implement (1), when you start a compilation you make a complete
copy of all the packages in the current environment, origined from
some lower level instead of the top level of the package-tree, except
you don't actualy copy the packages (hashtables) you merely set up an
indirect vector that is copy-on-write, so the first time you actually
modify any package that hashtable gets copied but the ones you haven't
modified don't need to get copied at all. If you implement hashtables
as balanced binary trees instead of as linear arrays, you only have
to copy the log(N) path down to the change rather than en masse the
whole contiguous hash array.
To implement (2) (Moon's suggestion I believe), whenever a macro
definition is compiled, you store it as a CMACRO instead of a normal
MACRO, whenever a global SETQ occurs, you use the CVALUE property
instead of the VALUE cell, likewise for CFUNCTION property instead of
FUNCTION cell, CDEFSTRUCT instead of DEFSTRUCT, etc. etc. When the
compiler is looking for the definition of a macro or auxilary function
needed for macro etc. it looks first for the C... which overrides the
normal definition if both are present. Meanwhile the compiler innerds
continues to use the normal definitions and totally ignore he C...
stuff, so none of the C... stuff can break the compiler itself.
CLtL should specify the semantics, namely that (1) the compiled-file
environment should be initialized to the current running environment
unless that is overridden (virgin LISP wanted instead for example),
(2) side-effects due to compiling definitions and SETQs etc. should
afect only the compiled-file environment not the compiler-innerds =
current-running-LISP environment, (3) when done with a batch of
compilations the compiled-file environment should be discarded unless
for some reason the operator wants it kept around for later use
compiling more files or debugging etc. -- The method of implementation
should be up to the compiler writer, with the above two methods (and
spawn extra process on Unix or other multi-virtual-machine systems as
a third method) merely suggested as ways it can done.
Alternately the above can be summarized by two postulates, (1) as it
says now, later loading the compiled file should have the same
semantics as later loading it interpreted, (2) anything needed to make
(1) work shouldn't modify the current running environment (in which
the compiler itself runs) in any way even temporarily except of course
for consuming memory and time.
(Opinion of REM)
∂16-Jan-86 1126 HEDRICK@RED.RUTGERS.EDU compiler enviornment
Received: from RED.RUTGERS.EDU by SU-AI.ARPA with TCP; 16 Jan 86 11:26:05 PST
Date: 16 Jan 86 14:25:13 EST
From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
Subject: compiler enviornment
To: common-lisp@SU-AI.ARPA
Message-ID: <12175752345.24.HEDRICK@RED.RUTGERS.EDU>
We have some experience with the compiler environment, based on
our UCI Lisp implementations. In our second-generation
UCI Lisp (called ELISP), we decided to separate the environment
of the compiler from that of the current core image. We carefully
kept all macros defined in a compiled file on separate properties
from the normal macro property, and did other related things.
We found that this confused users no end. For simple programs, none
of this mattered. For complex systems, we found that users would
normally supply macros, structure declarations, and functions that
were used to expand both the macros and structure declarations.
They would get very confused when macro compilation blew up because
it couldn't get to functions that they had defined in their core image.
I am sure that all of this could be solved by appropriate use of
EVAL-WHEN, and appropriate care in implementation. But I suspect
that most users would find it easier just to let the compiler use
the current Lisp environment. I don't think Lisp-level copy on write
is really needed. Most of our users are capable of writing
initialization files that load in all of the pieces of their system
that are needed for compilation. Then they have the choice of
compiling in their current core image, or getting a new one,
loading in the necessary initialization file, and compiling there.
I suspect it would be handy to have a way of making it easy to do
that in a subfork. A function like
(COMPILE-IN-SUBFORK files-to-load files-to-compile)
with some way to keep the subfork around for later compilations.
Unless I hear some proposal more convincing than those so far, I don't
think these mechanisms are ready for standardization yet.
-------
∂16-Jan-86 1407 REM@IMSSS compiler environment, how best to isolate side effects
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-16 14:05:55 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1986 January 16 14:04:27 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS> (this host known locally only)
To:COMMON-LISP@SU-AI.ARPA
CC:HEDRICK@RED.RUTGERS.EDU
Subject:compiler environment, how best to isolate side effects
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA
H> Date: 16 Jan 86 14:25:13 EST
H> From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
H> We carefully kept all macros defined in a compiled file on separate
H> properties from the normal macro property, ...
H> We found that this confused users no end.
Reasonable argument against Moon's separate-C-property idea, sigh. I
was hoping that would be the method of choice because it's the easiest
correct method to implement.
H> For complex systems, we found that users would normally supply macros,
H> structure declarations, and functions that were used to expand both
H> the macros and structure declarations. They would get very confused
H> when macro compilation blew up because it couldn't get to functions
H> that they had defined in their core image.
It sounds like your compiler used the C... properties exclusively,
refusing to use normal propertis even when the C... property didn't
exist. My suggestion (perhaps I was unclear) was to have the C...
properties mask the normal properties for the compiler operations on
the file, so if the user happened to define a normal macro or auxilary
function in the normal environment before starting the compilation
task the macro or auxilary function would still be seen unless it was
shadowed by a new definition within the file itself (and would be
shadowed only later in the file after the new definition actually
occurred). Thus the compiler would never "blow up because it couldn't
get to functions ..." as your compiler did. (In the other direction,
the innerds of the compiler and other things running in the normal
environment would not see the C... stuff at all. Perhaps that's the
phrase you saw and misapplied to the reverse case of compilation
seeing normal stuff.)
H> But I suspect that most users would find it easier just to let the
H> compiler use the current Lisp environment.
Remember the problem stated by somebody earlier in this discussion, if
you do that you can't build a new version of the compiler because
macros and auxilary functions being compiled will replace macros and
auxilary functions the compiler is trying to use to conduct the
compilation, causing the compiler to crash. We are trying to find a
bugfix for that problem so that it will be easy to compile compilers
in common-lisp.
H> Then they have the choice of compiling in their current core image, or
H> getting a new one, ...
H> I suspect it would be handy to have a way of making it easy to do
H> that in a subfork. A function like
H> (COMPILE-IN-SUBFORK files-to-load files-to-compile)
H> with some way to keep the subfork around for later compilations.
As was pointed out, on LISP machines and other single-address-space
machines, you can't do that except by discarding the current core
image that may have taken weeks to build up. It would be nice to solve
address-space problems (using "address space" in the general sense of
tag->value mapping such as value cell or functional properties etc.)
within LISP itself without assuming an underlying operating system that
supports multiple virtual machines (forks etc.).
H> Unless I hear some proposal more convincing than those so far, I don't
H> think these mechanisms are ready for standardization yet.
With this I agree. On machines with multiple virtual machines that can
be initialized to have identical memory contents but with
copy-on-write, most users will want the COMPILE-IN-SUBFORK feature,
although compiling a new version of the compiler will take special
care. On other machines without multiple virtual machines the whole
thing will need to be done within LISP itself somehow. The desiderata
(semantics) should be specified, perhaps somewhat like I proposed in
my previous message (compiled file equivalent to interpreted file, no
side effects propagate back to normal environment), leaving the
implementation method for the implementor to pick.
(Another example: I still dislike the insistance that property lists
be implemented as alternating lists instead of using whatever method
the implementor chooses. Balanced binary trees for property lists
would solve a lot of expensive-linear-search problems we were
discussing a few weeks ago, and the implementor should be able to
choose ASSOC lists or alternating or bbt or hashtable or whatever. You
don't need a whole new set of functions, since you can use optional or
keyword parameters for modifying the existing functions, such as
(ASSOC key alist) can give you normal ASSOC-list search, while
(ASSOC key altlist :FORMAT ALTLIST) can force it to handle
alternating lists if you use them somewhere explicitly, or
(ASSOC key balbinarytree :FORMAT BBT) can force it to handle balanced
binary trees, and finally
(ASSOC key plist :FORMAT PLIST) can give you whatever the
implementation is using for property lists.
Likewise (GET symbol key default) et al can be extended to
(GET bbt key default :FORMAT BBT), (REMPROP altlist key :FORMAT ALIST)
et al.)
If we can prove mathematically there's only one internal mechanism
that works, then we should set that in concrete in CLtL, otherwise not.
(Opinion of REM)
∂17-Jan-86 0303 GJC@MC.LCS.MIT.EDU compiler enviornment
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Jan 86 03:03:24 PST
Date: Fri, 17 Jan 86 06:04:14 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: compiler enviornment
To: HEDRICK@RED.RUTGERS.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 16 Jan 86 14:25:13 EST from Charles Hedrick <HEDRICK at RED.RUTGERS.EDU>
Message-ID: <[MC.LCS.MIT.EDU].786938.860117.GJC>
I agree, compiling and running in the same environment is just
something that users need to be aware of if they are the type that
like to debug their code using COMPILE-DEFUN in their ZMACS buffers,
as compared with the type that like to make a couple changes in their
sources and do MAKE-SYSTEM :COMPILE. If it were not for global special
declarations, macros, defstruct, defflavor and the like there really
wouldnt be much difference in semantics between the two styles.
That the implementations usually go to a bit of trouble to avoid
certain screws with defmacro and defflavor is nice of course.
∂17-Jan-86 0701 pyramid!bein@sri-unix compile environment..
Received: from SRI-UNIX.ARPA by SU-AI.ARPA with TCP; 17 Jan 86 07:01:11 PST
Received: by sri-unix.ARPA (4.12/4.16)
id AA23958; Fri, 17 Jan 86 06:56:36 pst
Received: by pyramid (4.12/3.14)
id AA10463; Fri, 17 Jan 86 04:07:56 pst
Date: 17 Jan 1986 04:00 PST
From: David Bein <pyramid!bein@sri-unix>
Subject: compile environment..
To: fahlman@cmu-cs-spice.ARPA
Cc: common-lisp@su-ai.ARPA
Message-Id: <506342289/bein@pyramid>
Scott:
Two cheers for Accent -- they have clones and do it via copy-on-write
One cheer for Unix -- they don't have copy-on-write..
How about the following?
(1) compile-file :affect-environment <val> :use-environment <val>
:load-result <val>
:affect-environment specifies whether or not it is permissible
to muck with current image in the process of effecting the
compilation. default: nil -- do not mess with my space
:use-environment specifies that the current environment is
needed (or not) for the compilation. default: nil always
be clean and use the "standard" environment.
:load-result says what to do with the result and does not
necessarily imply that the current environment will be
messed with in any ways other than what are implied if
you only load the result of compilation. default: nil
Letting the defaults for these be NIL and putting the handling
of them into the same gray-zone as some of the file ops implies
that they are standardized for those environments where they
make sense (and can be implemented) and simply ignored where
they can not be done or do not make sense.
(Look out for the black-zone)...
(2) compile :clone <val> :virgin <val> :in-current-env <explicit-progn-form>
:in-other-environment <explicit-progn-form>
:clone means explicitly do not mess with my process space
to compile my function. The result of the compilation, i.e.
the function object, magically finds it way into my space.
default: nil -- do it in my space -- mess with it too.
:virgin implies clone and do something akin to an exec
with proper redirection such that the result of the
compilation comes back as in :clone. Exactly what the
"clean" environment must look like should be well
specified as it is expected that this is the only
part which could easily be standardized.
default: nil -- do it in my space -- mess with it too.
:in-current-environment means evaluate forms in the current
environment and then :clone with the result being stuffed
back into my current space. This is somewhat akin to
eval-before-context-save or something like that.
default: nil -- this means nothing special if there is not some
kind of context saving mechanism going on other than yet another
kind of top-level eval-when-who-knows kind of form.
:in-other-environment means evaluate the forms after getting
into the new environment. It applies to either :clone or
:virgin. It is somewhat akin to eval-after-context-save
or something like that. The effects of this should not
be noticed in the post-compile environment.
default: nil -- this means nothing if there is no way
to get a new context or maybe it should be yet another
pre-form which acts like eval-when- ...
Somewhere in here we find that it is useful to have a working
definition of what is a process (from a CL point of view) and
that many things we would like to be able to do are limited
by the fact that we don't have a good handle on things. I
could very easily graft pieces from Accent or Unix into
a working process definition, but that is beyond the question
at hand. I guess your reply to Moon et al is just the tip of
the iceberg.
Comments?
--David
p.s. What about errors in compilation if we do it in another
process space?
∂17-Jan-86 0753 FAHLMAN@C.CS.CMU.EDU compile environment..
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Jan 86 07:53:48 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Jan 86 10:53:40-EST
Date: Fri, 17 Jan 1986 10:53 EST
Message-ID: <FAHLMAN.12175975952.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: David Bein <pyramid!bein@SRI-UNIX.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: compile environment..
In-reply-to: Msg of 17 Jan 1986 07:00-EST from David Bein <pyramid!bein at sri-unix>
David,
I think your suggestions are good ones for systems that can provide
these styles of compilation. I have a quibble or two about the
defaults, and am dubious about providing nay isolation for COMPILE, but
basically something like this would give the user the proper degree of
control.
I guess my preference would be to leave this sort of thing outside the
language standard, but let implementations that can support this stuff
use the same syntax by informal agreement. It seems to cause a lot of
confusion to put something into the standard but to indicate that it is
optional. Most of the environment-sensing functions were put into the
book in the spirit of "you don't have to provide this, but if you do it
should look like this". I get a lot of bug reports from people who
don't understand that some of this stuff is optional.
-- Scott
∂17-Jan-86 1628 DLW@SCRC-QUABBIN.ARPA time of evaluation
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Jan 86 16:28:42 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 236379; Fri 17-Jan-86 19:28:08-EST
Date: Fri, 17 Jan 86 19:28 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: time of evaluation
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12175556144.BABYL@C.CS.CMU.EDU>
Message-ID: <860117192843.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 15 Jan 1986 20:27 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I guess this business of stashing
the compiler's state changes in funny undoable places is about the best
you can do. I wouldn't like to see this solution cast in concrete for
everyone, though.
There's no reason that this solution, or any other internal
implementation technique used in a Lisp system, should be cast in
concrete for everyone. It's important to distinguish between the
defined semantics of Common Lisp, and implementation techniques.
The semantic question is what compile-file does vis a vis the Lisp
environment in which compile-file is called. Revising my earlier
twofold choice in light of something Moon said, there are three
possibilities:
(1) The files being compiled see an empty Lisp environment when the
compilation starts. The Lisp environment that called compile-file is
untouched.
(2) The files being compiled see a Lisp environment identical to the one
from which compile-file was called. The Lisp environment that called
compile-file is untouched.
(3) The files being compiled see a Lisp environment identical to the one
from which compile-file was called. The Lisp environment that called
compile-file is modified by side-effects performed on the Lisp
environment during the compilation.
Personally, I would find style (1) to be painful and inconvenient even
if my machine could switch to a new Lisp environment in two nanoseconds,
because I want the compilation to see the state in my Lisp environment.
Think of people who define their favorite macros in their init files,
who would then have to create some sort of "compiler init file" to set
up the compilation environment for all of their programs, as a simple
example. I admit that this is a matter of philosophy of programming
environment that other people could validly disagree with. I think that
(2) is what I want, although I can see some benefits in (3) under some
circumstances.
Do we have to make a decision on this? If we feel that this behavior
must be made consistent from one Common Lisp to the next in order to
allow portability, that would mean that we have to make a decision.
Otherwise we can just say "Common Lisp doesn't specify it." But let's
make sure that we're not introducing a new way to make porting not work.
∂17-Jan-86 1644 DLW@SCRC-QUABBIN.ARPA compiler environment, how best to isolate side effects
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Jan 86 16:42:48 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 236384; Fri 17-Jan-86 19:41:45-EST
Date: Fri, 17 Jan 86 19:42 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: compiler environment, how best to isolate side effects
To: REM%IMSSS@SU-SCORE.ARPA, COMMON-LISP@SU-AI.ARPA
cc: HEDRICK@RED.RUTGERS.EDU
In-Reply-To: The message of 16 Jan 86 17:04-EST from Robert Elton Maas <REM@IMSSS>
Message-ID: <860117194222.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Your "C-property" stuff is an implementation-oriented description of
what I referred to as a "subjunctive environment". Contrary your mail,
what Hedrick said is NOT a "reasonable argument against" this. In
Hedrick's system, macros were placed into the subjunctive environment,
but functions were not. That's why users were confused no end. Had
everything been put into the sujunctive environment, it would have
worked fine.
The Symbolics system right now is like what Hedrick describes, except
that EVAL-WHEN is available. So users can carefully put EVAL-WHEN's
around functions that are needed in the subjunctive environment, so that
the macros that call them will work. Unfortunately, (1) you have to
remember to put in the EVAL-WHEN's, and understand what they mean, and
(2) when you do compile-file, the function is left around in your Lisp
environment. While I haven't seen a lot of evidence of confused users,
I agree that this is the sort of thing I'd expect to confuse people,
since it's rather subtle. Doing the "subjunctive environment" would
make everything work right without muss or fuss. We would have done
it by now except that it's so hard to implement in this architecture.
I'm getting pretty close to agreeing that this isn't something we can
tackle easily by simply dictating a behavior in CLtL. Instead we'll
have to come up with one or two conventions so that portability can be
achieved.
∂17-Jan-86 1813 hplabs!snyder@hplabs.ARPA Re: time of evaluation
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 17 Jan 86 18:13:35 PST
Received: by hplabs.ARPA ; Fri, 17 Jan 86 18:12:12 pst
Date: Friday, January 17, 1986 18:10:18
From: snyder@hplabs.ARPA
Subject: Re: time of evaluation
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860117192843.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
There's no reason that this solution, or any other internal
implementation technique used in a Lisp system, should be cast in
concrete for everyone. It's important to distinguish between the
defined semantics of Common Lisp, and implementation techniques.
However, if there are mechanisms being used to support side-effect-free (or at
least "reduced side effect") file compilation, it would be nice if there were
a portable interface by which those mechanisms could be accessed by language
extensions (for example, object oriented programming extensions).
It would also be nice if those mechanisms were as effective as we know how to
(portably) make them. For example, I believe a side-effect avoiding mechanism
should have the following properties:
1. It should distinguish forms being compiled from forms being
interpreted during compilation (e.g., because the compiler is
interpreted, or because a macro expansion function is interpreted, or
because a break loop was entered). Only a form being compiled should
look in a special place for macro definitions, for example.
2. It should distinguish between different invocations of compile-file,
as might arise if one compile-file entered a break loop and the
user started another compile-file while the first was still active.
We might be able to standardize on minimum requirements for a mechanism for
"reduced side-effect compilation". If the requirements are reasonable, we
might also be able to standardize on that mechanism being used by default,
with options provided to select other (nonstandard) techniques, as has been
suggested.
-------
∂19-Jan-86 1537 pyramid!bein@sri-unix floating point question
Received: from SRI-UNIX.ARPA by SU-AI.ARPA with TCP; 19 Jan 86 15:37:14 PST
Received: by sri-unix.ARPA (4.12/4.16)
id AA02136; Sun, 19 Jan 86 15:34:41 pst
Received: by pyramid (4.12/3.14)
id AA20488; Sun, 19 Jan 86 15:10:53 pst
Date: 19 Jan 1986 14:55 PST
From: David Bein <pyramid!bein@sri-unix>
Subject: floating point question
To: fahlman@cmu-cs-spice.ARPA
Cc: common-lisp@su-ai.ARPA
Message-Id: <506559328/bein@pyramid>
Scott:
I am wondering about the following bizarre character of
the Common Lisp treatment of floats and ratios when doing
comparisons, specifically = ..
Suppose that you have X and Y where x is a SINGLE-FLOAT and
Y is a RATIO. Also suppose that X is 0.0. Mathematically speaking
no ratio is 0. So, according to rules of floating point contagion,
you are supposed to convert Y to be a SINGLE-FLOAT which may result
in a SINGLE-FLOAT == 0.0 due to rounding all of which results in
notions like floating point 0.0 equals a non-zero ratio
due to conversion. If I take another approach for = and test
that the float is indeed 0.0 and thus conclude that no ratio
(by rules of ratio canonicalization) is 0, then I end up with
anomalies like (= X Y) != (= X (FLOAT Y X)) which does seem
strange, but from a mathematical point of view, (= X Y)
in this case should be FALSE. What do you think?
Please pardon me if this question has been asked and/or resolved
in some previous mail.
--David
∂19-Jan-86 1559 RPG
∂19-Jan-86 1335 unido!uklirb!przy@seismo.CSS.GOV
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 19 Jan 86 13:35:37 PST
Received: from unido.UUCP by seismo.CSS.GOV with UUCP; Sun, 19 Jan 86 16:28:24 EST
Received: by unido.uucp with uucp; Sun, 19 Jan 86 22:14:23 -0100
Received: by uklirb.UUCP (4.12/4.7)
id AA02054; Sun, 19 Jan 86 21:58:39 -0100
Date: Sun, 19 Jan 86 21:58:39 -0100
From: unido!uklirb!przy@seismo.CSS.GOV (Gebhard Przyrembel)
Message-Id: <8601192058.AA02054@uklirb.UUCP>
To: common-lisp-request@su-ai.arpa
Return-Path: <uklirb!przy> (from unido.uucp)
Please, add me to your mailing-list.
Thanks in advance,
Gebhard
/---------------------------------------------------------\
| e-mail: przy@uklirb.UUCP or |
| ..!mcvax!unido!uklirb!przy |
| Real-Name: Gebhard Przyrembel |
| University Kaiserslautern |
| Departement of Computer Sciene |
| D-6750 Kaiserslautern |
| West-Germany |
\---------------------------------------------------------/
(add-dis common)
"unido!uklirb!przy"@seismo.CSS.GOV
∂19-Jan-86 1706 FAHLMAN@C.CS.CMU.EDU floating point question
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jan 86 16:58:13 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 19 Jan 86 19:57:28-EST
Date: Sun, 19 Jan 1986 19:57 EST
Message-ID: <FAHLMAN.12176599253.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: David Bein <pyramid!bein@SRI-UNIX.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: floating point question
In-reply-to: Msg of 19 Jan 1986 17:55-EST from David Bein <pyramid!bein at sri-unix>
I'm not sure why you are asking me specifically about this. Of all the
people on the Common Lisp mailing list, I'm probably the one who cares
the least about the fine points of floating-point roundoff hackery and
related mathematicalia. But anyway...
It is well known that floating point numbers are mere approximations to
mathematical truth, due to roundoff error. So I see no paradox here.
No Common Lisp ratio is strictly equal to zero (else it would be reduced
to an integer), but it is quite possible to have one whose closest
approximation in the domain of short-floats is 0.0. So what? There are
an infinite number of other examples where, due to roundoff, two arithmetic
expressions that are supposed to lead to identical results in fact
produce slightly different floating point numbers. No paradox, just the
result of dealing with an approximation.
-- Scott
∂19-Jan-86 1736 Moon@SCRC-STONY-BROOK.ARPA floating point question
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Jan 86 17:36:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 396264; Sun 19-Jan-86 20:17:28-EST
Date: Sun, 19 Jan 86 20:17 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: floating point question
To: David Bein <pyramid!bein@SRI-UNIX.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <506559328/bein@pyramid>
Message-ID: <860119201711.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Floating-point arithmetic is never exact, so I don't think it's any
more surprising if (= 0.0 1/123456789123456789123456789123456789)
than if (= 1.0 (+ 1.0 1e-10)).
∂20-Jan-86 0951 BACH@SU-SCORE.ARPA Spelling correction
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Jan 86 09:51:48 PST
Date: Mon 20 Jan 86 09:48:22-PST
From: Rene Bach <BACH@SU-SCORE.ARPA>
Subject: Spelling correction
To: common-lisp@SU-AI.ARPA
Message-ID: <12176783291.16.BACH@SU-SCORE.ARPA>
I am new on this list (please forgive me if this topic has been discussed
already).
It has been our experience that using the spelling correction facilities
provided by Interlisp are very useful to provide nice user interfaces.
It is also my belief that to do flexible symbol matching requires
spelling correction.
My question is: why doesn't CL include a specification for a spelling
correction function. The description of the Interlisp functions could be
used as specification for the I/O. The choice of the algorithm could
be left open.
Regards
Rene Bach
-------
∂20-Jan-86 1023 FAHLMAN@C.CS.CMU.EDU Spelling correction
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jan 86 10:23:08 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Jan 86 13:23:11-EST
Date: Mon, 20 Jan 1986 13:23 EST
Message-ID: <FAHLMAN.12176789605.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Rene Bach <BACH@SU-SCORE.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Spelling correction
In-reply-to: Msg of 20 Jan 1986 12:48-EST from Rene Bach <BACH at SU-SCORE.ARPA>
Common Lisp deliberately specifies very little about the top-level
command loop. This is so that many "cultures" (styles of dealing with
the machine) can be supported on top of a common language that allows
code packages to be shared.
The overwhelming majority of Common Lisp implementors and users, at
least at the start, come from the Maclisp tradition in which code is
created by the use of some text editor, usually Emacs-like and usually
written in the Lisp itself. CMU's Hemlock editor is a public-domain
implementation of such a thing. It is not 100% portable, since it
depends on the host system's screen management, but the majority of
Common Lisp vendors who do not already have a good Emacs implementation
on their machines are importing Hemlock. Most of these Emacs-like
systems provide the user with an editor top-level mode, in which
expressions are created within the editor and then are passed into the
Lisp for evaluation. This provides full editing power (including
spelling correction, word abbreviation mode, and the like) plus a buffer
that records the history of the session. Instead of using a specialized
mechanism for repeating and altering earlier commands, you just grab
what you want from the buffer and fix it up before transmitting it to
the Lisp.
Anyone who is more comfortable with the Interlisp style of structure
editing, DWIM, Masterscope, history, etc., is free to implement this on
top of Common Lisp, and I suspect that at least one manufacturer is
going to follow this route (though I hope they eventually provide a
Hemlock-style interface as well).
One could argue the merits of the two styles, but the point for Common
Lisp is that they can coexist happily and that we don't need to
standardize on either of them. Portable code lives below this level.
-- Scott
∂20-Jan-86 1052 DCP@SCRC-QUABBIN.ARPA Spelling correction
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Jan 86 10:52:39 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 236886; Mon 20-Jan-86 13:51:40-EST
Date: Mon, 20 Jan 86 13:56 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Spelling correction
To: Rene Bach <BACH@SU-SCORE.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <12176783291.16.BACH@SU-SCORE.ARPA>
Message-ID: <860120135654.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon 20 Jan 86 09:48:22-PST
From: Rene Bach <BACH@SU-SCORE.ARPA>
I am new on this list (please forgive me if this topic has been discussed
already).
It has been our experience that using the spelling correction facilities
provided by Interlisp are very useful to provide nice user interfaces.
It is also my belief that to do flexible symbol matching requires
spelling correction.
My question is: why doesn't CL include a specification for a spelling
correction function. The description of the Interlisp functions could be
used as specification for the I/O. The choice of the algorithm could
be left open.
Base my following reaction on never having used Interlisp but only heard
about it and some of its 'features.'
The only 'spelling corrector' I've heard of in Interlisp is a DWIM
facility to change the name of variables out from under you because you
mistyped them. I don't believe in that kind of programming, since that
will, among other things, hide bugs that will resurface indefinitely
later if you happen to name a variable the same as your previous
misspelling. Errors should be signalled. DWIMing is a function of the
application program only (provided CL had an error system to deal with
errors) and is not a function of the system itself. For example, if I
mistyped
*BAX*
when I meant
*BAZ*
I want an error. Someday I may legally define *BAX*.
[Shift to programming enviroments...] I also make use of the compiler
to tell me when variables are unknown and declared special (which is the
most common manifestation of my misspellings) and functions being called
that aren't defined.
If there is a spelling corrector of this type, it should be integrated
into the system at the user-interface level, which is probably out of
bounds for CLtL.
∂20-Jan-86 1859 RPG the Common-Lisp mailinglist
∂20-Jan-86 1810 enea!kuling!victor@seismo.CSS.GOV the Common-Lisp mailinglist
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 20 Jan 86 18:10:32 PST
Return-Path: <enea!kuling!victor>
Received: from enea.UUCP by seismo.CSS.GOV with UUCP; Mon, 20 Jan 86 21:01:29 EST
Received: by enea.UUCP; Tue, 21 Jan 86 02:33:57 +0100 (MET)
Received: by kuling.UUCP; Mon, 20 Jan 86 19:28:15 -0100
Date: Mon, 20 Jan 86 19:28:15 -0100
From: enea!kuling!victor@seismo.CSS.GOV (Bjorn Victor)
Message-Id: <8601201828.AA11512@kuling.UUCP>
To: "common-lisp-request@su-ai"@seismo.CSS.GOV
Cc: victor@seismo.CSS.GOV
Subject: the Common-Lisp mailinglist
I'd be happy to join the mailinglist. I use and maintain Hedrick's
implementation on TOPS-20 (have two 2060's), but we are not on any net
(yet), so I'll use this address until we get on it.
If it's OK with you, I'll forward articles of special interest to my
colleagues here at the department.
--Bjorn Victor UUCP: {mcvax,seismo}!enea!kuling!victor
Computing Science Dept/UPMAIL ARPA: enea!kuling!victor@SEISMO.CSS.GOV
Uppsala University, PO Box 2059
S-750 02 UPPSALA, SWEDEN
(add-dis common)
"enea!kuling!victor"@SEISMO.CSS.GOV
∂21-Jan-86 0836 gls@THINK-AQUINAS.ARPA Spelling correction
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jan 86 08:36:20 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Tue, 21 Jan 86 11:36:09 est
Date: Tue, 21 Jan 86 11:36 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Spelling correction
To: DCP@SCRC-QUABBIN.ARPA, BACH@SU-SCORE.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860120135654.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <860121113658.6.GLS@THINK-YON.ARPA>
Date: Mon, 20 Jan 86 13:56 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Mon 20 Jan 86 09:48:22-PST
From: Rene Bach <BACH@SU-SCORE.ARPA>
...
My question is: why doesn't CL include a specification for a spelling
correction function. The description of the Interlisp functions could be
used as specification for the I/O. The choice of the algorithm could
be left open.
Base my following reaction on never having used Interlisp but only heard
about it and some of its 'features.'
The only 'spelling corrector' I've heard of in Interlisp is a DWIM
facility to change the name of variables out from under you because you
mistyped them.
Let me observe that there are several distinct things that may be desired:
(1) DETECTION of spelling errors
(2) CORRECTION of spelling errors.
(2) PREVENTION of spelling errors.
The correction process may proceed in different ways depending on how the
error was detected. In some cases it is easier to prevent the error in the
first place.
The most general way in which spelling errors are "detected" is that a compiler
warning or interpreter error is issued, and maybe you get a debugging breakpoint.
This is not always the easiest way to correct the error.
The Symbolics implementation handles undefined variables and functions at top level
in a more useful way. First of all, it looks around in other packages to see
whether a different symbol of the same name has the appropriate definition; if so,
it offers to make the substitution. This is a kind of spelling correction (the
package name having been "misspelled"). Failing that, it prints a warning and
offers the opportunity to type a rubout or other input editor command rather than
having to go through the heavy-duty debugger.
Here at TMC we have an additional hack that allows the <complete> key to operate in
nearly all contexts, including the top level. Frequently I need only type
R E N <complete> to get "RENAME-WITHIN-NEW-DEFINITION-MAYBE" on the screen.
This is spelling correction before the fact rather than after.
It would be easy, in a similar manner, to make <complete> (or Meta-$) examine the
previous word and apply a spelling-correction algorithm to it. This is explicit
correction rather than implicit.
So there are many styles for dealing with the spelling problem. I think
it would be premature to standardize on any one.
--Guy
∂21-Jan-86 1039 SCHUMACHER@HP-HULK
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 21 Jan 86 10:38:51 PST
Received: from HP-HULK by hplabs.ARPA ; Tue, 21 Jan 86 10:37:24 pst
Date: Tue 21 Jan 86 10:37:59-PST
From: SCHUMACHER%HP-HULK@HPLABS
To: common-lisp@su-ai.ARPA
-------
∂22-Jan-86 1324 DDYER@SCRC-QUABBIN.ARPA Spelling correction
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 22 Jan 86 13:24:41 PST
Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 237773; Wed 22-Jan-86 16:23:02-EST
Received: from PURPLE.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 168110; Wed 22-Jan-86 13:24:03-PST
Date: Wed, 22 Jan 86 13:26 PST
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: Spelling correction
To: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>,
Rene Bach <BACH@SU-SCORE.ARPA>, common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <860120135654.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <860122132621.2.DDYER@PURPLE.SWW.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Mon, 20 Jan 86 13:56 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Mon 20 Jan 86 09:48:22-PST
From: Rene Bach <BACH@SU-SCORE.ARPA>
I am new on this list (please forgive me if this topic has been discussed
already).
It has been our experience that using the spelling correction facilities
provided by Interlisp are very useful to provide nice user interfaces.
It is also my belief that to do flexible symbol matching requires
spelling correction.
My question is: why doesn't CL include a specification for a spelling
correction function. The description of the Interlisp functions could be
used as specification for the I/O. The choice of the algorithm could
be left open.
Base my following reaction on never having used Interlisp but only heard
about it and some of its 'features.'
You are somewhat under-informed about the Interlisp spelling corrector. Here's
the straight scoop from one who knows.
Underlying everything, Interlisp has a function called FIXSPELL which has
lots of optional arguments, but which essentially checks a "misspelled"
symbol against a specified list of possible corrections. The parameters
control how FIXSPELL responds to spelling errors or various degrees of
severity. Depending on the various severity thresholds and the response
specification, FIXSPELL can return a "correction" without comment, with
a comment/warning message, with a Y-OR-N-P type response, or with an
error.
Interlisp has several mechanisms for automatically maintaining "spelling lists";
for example, it keeps a lists of "system" functions "system" variables,
"user" functions and "user" variables.
DWIM is an entirely separate facility, which among other things, can
invoke FIXSPELL to attempt to find a correction. This is the use of
the spelling corrector which is most often encountered by the casual
Interlisp user. Forms you type to a lisp listener are passed to DWIM
if an error occurs, and (various switches permitting) FIXSPELL can be
invoked to find semantically reasonable corrections. DWIM (and
therefore FIXSPELL) are also invoked by the compiler. Due to the
form-based nature of Interlisp's environment, changes made by DWIM
are automatically propagated to the sources. ε2All ε0changes made
by DWIM are undoable.
Summary: FIXSPELL is a utility which we could use. DWIM is a completely
separate facility, which is controversial even within the Interlisp community.
Most of use have a love/hate relationship with it, but few choose to turn it
off.
----
The only 'spelling corrector' I've heard of in Interlisp is a DWIM
facility to change the name of variables out from under you because you
mistyped them. I don't believe in that kind of programming, since that
will, among other things, hide bugs that will resurface indefinitely
later if you happen to name a variable the same as your previous
misspelling.
This is a misconception; DWIM (as used by the compiler) actually fixes
the sources, so the bug won't resurface later. The choice to fix
the sources "silently" "noisily" or "with confirmation only" is
available to the user. The really important thing you apparently
didn't know is that when DWIM fixes something itε2 staysε0 fixed; So
today's Error-fixed-by-dwim doesn't become tomorrow's non-bug
because *BAX* is now defined.
For example, if in a lispm compilation you get the warning "Function foo-bax-mumble is undefined",
DWIM might instead have run an interaction such as
Function FOO-BAX-MUMBLE is undefined. Do you mean FOO-BAR-MUMBLE?
and if you respond Y, it fixes the source for you once and for all. I always
found this extremely user-friendly, since DWIM was almost always right and
since it saved me the trouble of doing another edit-compile cycle.
∂22-Jan-86 1738 BACH@SU-SCORE.ARPA Re: Spelling correction
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Jan 86 17:37:02 PST
Date: Wed 22 Jan 86 17:16:26-PST
From: Rene Bach <BACH@SU-SCORE.ARPA>
Subject: Re: Spelling correction
To: DDYER@SCRC-RIVERSIDE.ARPA
cc: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860122132621.2.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <12177389147.33.BACH@SU-SCORE.ARPA>
Thank you. I have been waiting until the first burst of comments subsided
before coming back. Yes. what I really had in mind were the equivalent
of FIXSPELL and MISSPELLED? (see interlisp manual, in the 1978 edition
it's page 17.18, for a specification of those functions. I'll type in
the specs if asked to do so.)
And I am not a LISP developer, but I am a user. I use LISP to write
expert systems and believe that Common Lisp should be a helpful tool
for the researchers in the different areas of AI. Thus many of the
comments about DWIM and code development issues were somewhat off.
I believe that FIXSPELL and MISSPELLED? functions have a wide range of
utility and deserve to be included in C-L. Think of them as being
smart equivalent of the MEMBER function.
-------
∂22-Jan-86 2048 shebs%utah-orion@utah-cs.arpa Re: Spelling correction
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 22 Jan 86 20:48:31 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA10541; Wed, 22 Jan 86 21:49:10 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA20265; Wed, 22 Jan 86 21:49:06 MST
Date: Wed, 22 Jan 86 21:49:06 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8601230449.AA20265@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Re: Spelling correction
I can't get really enthused about spelling correction, even if it's
just a pair of relatively innocuous functions. Common Lisp is already
pretty fat ("pleasingly plump"?), and spelling correction really
falls into a gray area, if one applies the agreed-upon inclusion criteria.
Yellow pages seems appropriate, unless someone wants to argue that
implementors can make it significantly better by doing implementation
dependent hacks?
stan
∂22-Jan-86 2228 shebs%utah-orion@utah-cs.arpa Re: Spelling correction
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 22 Jan 86 20:48:31 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
id AA10541; Wed, 22 Jan 86 21:49:10 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
id AA20265; Wed, 22 Jan 86 21:49:06 MST
Date: Wed, 22 Jan 86 21:49:06 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8601230449.AA20265@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Re: Spelling correction
I can't get really enthused about spelling correction, even if it's
just a pair of relatively innocuous functions. Common Lisp is already
pretty fat ("pleasingly plump"?), and spelling correction really
falls into a gray area, if one applies the agreed-upon inclusion criteria.
Yellow pages seems appropriate, unless someone wants to argue that
implementors can make it significantly better by doing implementation
dependent hacks?
stan
∂23-Jan-86 0657 FAHLMAN@C.CS.CMU.EDU Spelling correction
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jan 86 06:57:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 23 Jan 86 09:58:31-EST
Date: Thu, 23 Jan 1986 09:58 EST
Message-ID: <FAHLMAN.12177538793.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Rene Bach <BACH@SU-SCORE.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Spelling correction
In-reply-to: Msg of 22 Jan 1986 20:16-EST from Rene Bach <BACH at SU-SCORE.ARPA>
I agree that a set of simple spelling error detection/correction
facilities would make a useful addition to the Yellow pages. If people
eventually decide that these things are universally used, we could move
them into the standard language at that time.
We already have such a package built into Hemlock, though I'm not sure
how easy it would be to extract it.
I have a hunch that a list of legal words is not the best possible
interface to this thing. You want to have a spelling dictionary object
type that can be built from a set of words, and that can be modified
later. Probably once this reaches a certain size you want this object
to be a hash-table or balanced binary tree or something like that, and
not a simple list. The spell checking and correcting functions would
operate on one of these objects, and not on the raw word-list.
-- Scott
∂23-Jan-86 1333 gls@THINK-AQUINAS.ARPA [vrotney@isi-vaxa.ARPA: Forwarded]
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 23 Jan 86 13:33:20 PST
Received: from quentin by GODOT.THINK.COM via CHAOS; Thu, 23 Jan 86 16:33:01 est
Date: Thu, 23 Jan 86 16:33 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: [vrotney@isi-vaxa.ARPA: Forwarded]
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860123163356.1.GLS@THINK-QUENTIN.ARPA>
Can anyone help with the following problem?
--Guy
Date: Wed, 22 Jan 86 18:00:58 pst
From: vrotney@isi-vaxa.ARPA (Bill Vrotney)
Guy Steele,
I am implementing our FSD on the HP 9000 machines
in Common Lisp. I need a public domain loop macro
that is roughly equivalent to the Zetalisp version,
but will compile under Common Lisp. I copied over
M.I.T.'s loop macro, but Common Lisp doesn't seem
to have the "*features*" that it needs. Do you
know of any such public domian loop macro designed
for Common Lisp?
Bill Vrotney
USC/Information Sciences Institute
vrotney@ISI-VAXA.ARPA
∂23-Jan-86 1847 mips!escargot.earl@glacier time of evaluation
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 23 Jan 86 18:47:28 PST
Received: by glacier with Sendmail; Thu, 23 Jan 86 18:46:49 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
id AA29948; Thu, 23 Jan 86 13:57:02 pst
Received: by escargot.UUCP (4.12/4.7)
id AA23779; Thu, 23 Jan 86 13:56:39 pst
Date: Thu, 23 Jan 86 13:56:39 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8601232156.AA23779@escargot.UUCP>
To: DLW@SCRC-QUABBIN.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: Daniel L. Weinreb's message of Fri, 17 Jan 86 19:28 EST
Subject: time of evaluation
Date: Fri, 17 Jan 86 19:28 EST
From: Daniel L. Weinreb <glacier!DLW@SCRC-QUABBIN.ARPA>
...
(1) The files being compiled see an empty Lisp environment when the
compilation starts. The Lisp environment that called compile-file is
untouched.
...
Personally, I would find style (1) to be painful and inconvenient even
if my machine could switch to a new Lisp environment in two nanoseconds,
because I want the compilation to see the state in my Lisp environment.
Think of people who define their favorite macros in their init files,
who would then have to create some sort of "compiler init file" to set
up the compilation environment for all of their programs, as a simple
example.
It is annoying to start out in a empty environment, but it is the only
way you'll get people to write portable stuff. If compiling a file
something implicitly depends on their favorite personal macros, then
nobody else can use it. On the other hand, all that's required to
live with the empty compiler environment is (REQUIRE DLW-DEFINITIONS).
You just get in the habit of putting that in every file you create...
∂23-Jan-86 2124 Moon@SCRC-STONY-BROOK.ARPA [vrotney@isi-vaxa.ARPA: Forwarded]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Jan 86 21:23:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 400276; Fri 24-Jan-86 00:23:22-EST
Date: Fri, 24 Jan 86 00:23 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: [vrotney@isi-vaxa.ARPA: Forwarded]
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860123163356.1.GLS@THINK-QUENTIN.ARPA>
Message-ID: <860124002342.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 23 Jan 86 16:33 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Can anyone help with the following problem?
Date: Wed, 22 Jan 86 18:00:58 pst
From: vrotney@isi-vaxa.ARPA (Bill Vrotney)
I need a public domain loop macro
that is roughly equivalent to the Zetalisp version,
but will compile under Common Lisp.
I don't have one, but if someone wants to write one I may be
able to offer some guidance. I'd like to see it redesigned,
but perhaps there is enough demand for a simple reimplementation
in Common Lisp of the existing specification.
∂23-Jan-86 2253 GSB@MC.LCS.MIT.EDU common-lisp loop
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 Jan 86 22:53:22 PST
Date: Fri, 24 Jan 86 01:54:14 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: common-lisp loop
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].794262.860124.GSB>
A group at DEC in Hudson had one which had been derived from, i think,
the source used in Symbolics release 5.something. I had been going to
look it over, but never did; i no longer know where i put the source,
if i ever had it online. If someone at hudson could get ahold of this
from the natural language group (or linguistics or somesuch) i could
check it to see if it really did correspond to a fairly recent loop.
(They are the group a couple rows of cubicles over from the vaxlisp
people, at least during the summer. I was over there once but all the
vaxlisp people were out partying or something.) If not i suppose i
could just sit down with the latest source and do the conversion.
∂24-Jan-86 1258 fateman@dali.berkeley.edu comparisons between floats and ratios
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 24 Jan 86 12:57:59 PST
Received: by ucbvax.berkeley.edu (5.44/1.7)
id AA26935; Fri, 24 Jan 86 12:56:18 PST
Received: by dali.berkeley.edu (5.44/5.16)
id AA29507; Fri, 24 Jan 86 12:25:47 PST
Date: Fri, 24 Jan 86 12:25:47 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601242025.AA29507@dali.berkeley.edu>
To: common-lisp@su-ai.arpa
Subject: comparisons between floats and ratios
There is a rule (top of p 194, CLtL) indicating that CL preserves
"as much accuracy as possible" (although not guaranteeing it).
Thus when two numeric values are operated upon, the coercion
is to the larger precision, which tends to preserve more accuracy.
To be consistent with this rule, operations which combine floats of
any precision with ratios should convert floats to ratios, not the
reverse.
Any float (except possibly IEEE NaN and infinity) can be converted to a
ratio without loss of precision. (and Nan=0/0, inf = 1/0 might even be
used). Of course the rational answer could be re-floated if required.
This would solve the problem of incorrect equality of 0.0 with a
non-zero but small ratio which "underflows".
Now consider comparing the floating point number 0.5 with an integer
sufficiently large as to overflow the exponent range of floats. The
comparison is "an error", according to CLtL (p 194). If one is to
ensure correct handling of the large number of numeric data types
in the language specification, I think the comparison should return
the mathematically correct answer.
(Alternatively, one could consider re-building all built-in functions
for applications like Macsyma.)
∂24-Jan-86 1618 Cassels@SCRC-STONY-BROOK.ARPA comparisons between floats and ratios
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Jan 86 16:18:39 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 401241; Fri 24-Jan-86 19:18:12-EST
Date: Fri, 24 Jan 86 19:20 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: comparisons between floats and ratios
To: fateman@dali.berkeley.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <8601242025.AA29507@dali.berkeley.edu>
Message-ID: <860124192014.5.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>
Date: Fri, 24 Jan 86 12:25:47 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
There is a rule (top of p 194, CLtL) indicating that CL preserves
"as much accuracy as possible" (although not guaranteeing it).
Thus when two numeric values are operated upon, the coercion
is to the larger precision, which tends to preserve more accuracy.
To be consistent with this rule, operations which combine floats of
any precision with ratios should convert floats to ratios, not the
reverse.
By introducing a floating-point number into a computation, you're
introducing a [hopefully] controlled inaccuracy. CLtL is just trying to
preserve that amount of inaccuracy.
Any float (except possibly IEEE NaN and infinity) can be converted to a
ratio without loss of precision. (and Nan=0/0, inf = 1/0 might even be
used). Of course the rational answer could be re-floated if required.
This would solve the problem of incorrect equality of 0.0 with a
non-zero but small ratio which "underflows".
Now consider comparing the floating point number 0.5 with an integer
sufficiently large as to overflow the exponent range of floats. The
comparison is "an error", according to CLtL (p 194). If one is to
ensure correct handling of the large number of numeric data types
in the language specification, I think the comparison should return
the mathematically correct answer.
(Alternatively, one could consider re-building all built-in functions
for applications like Macsyma.)
You bring up three issues:
- the coercion rules for mixed-type operations (+, -, *, etc.)
- the coercion rules for mixed-type comparisons (=, <, etc.)
- "correct answers" for mixed-type comparisons vs. blowing out
I believe that although they are related, they are orthogonal. So I
will discuss them separately.
I don't think that you really want the coercion rules for operations to
prefer rational arithmetic to floating-point. Consider that (+ x 1)
will leave you with a rational result. Remember that rational
canonicalization means you can't distinguish a "ratio" 1/1 from an
integer 1. You'd have to be incredibly compulsive to keep your
computations from consing ratios and taking forever.
The reason we keep floating-point around is to do computations
efficiently. By introducing a float, you're saying, "I know the answer
might not be exactly correct, but I know what I'm doing -- just give me
an answer, and give it to me fast." [-: I do know that a lot of people
who use floating-point don't know what they're doing. But we should
pretend they do. :-]
You might want comparisons to be done rationally, although pretending
that 0.0 is the same as 0 seems foolish to me. And the efficiency issue
remains, since (< x 1) would most likely cons you a ratio of bigna.
I do agree that you'd like to get answers to any comparison that doesn't
involve NaNs. But that's possible even with the current CLtL coercion
rules. In the next release of the Symbolics system, mixed-type
comparisons are done in floating-point ala CLtL, but over- and underflow
are accounted for so that "correct" answers are always given.
∂24-Jan-86 1935 Cassels@SCRC-STONY-BROOK.ARPA comparisons between floats and ratios
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Jan 86 16:18:39 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 401241; Fri 24-Jan-86 19:18:12-EST
Date: Fri, 24 Jan 86 19:20 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: comparisons between floats and ratios
To: fateman@dali.berkeley.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <8601242025.AA29507@dali.berkeley.edu>
Message-ID: <860124192014.5.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>
Date: Fri, 24 Jan 86 12:25:47 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
There is a rule (top of p 194, CLtL) indicating that CL preserves
"as much accuracy as possible" (although not guaranteeing it).
Thus when two numeric values are operated upon, the coercion
is to the larger precision, which tends to preserve more accuracy.
To be consistent with this rule, operations which combine floats of
any precision with ratios should convert floats to ratios, not the
reverse.
By introducing a floating-point number into a computation, you're
introducing a [hopefully] controlled inaccuracy. CLtL is just trying to
preserve that amount of inaccuracy.
Any float (except possibly IEEE NaN and infinity) can be converted to a
ratio without loss of precision. (and Nan=0/0, inf = 1/0 might even be
used). Of course the rational answer could be re-floated if required.
This would solve the problem of incorrect equality of 0.0 with a
non-zero but small ratio which "underflows".
Now consider comparing the floating point number 0.5 with an integer
sufficiently large as to overflow the exponent range of floats. The
comparison is "an error", according to CLtL (p 194). If one is to
ensure correct handling of the large number of numeric data types
in the language specification, I think the comparison should return
the mathematically correct answer.
(Alternatively, one could consider re-building all built-in functions
for applications like Macsyma.)
You bring up three issues:
- the coercion rules for mixed-type operations (+, -, *, etc.)
- the coercion rules for mixed-type comparisons (=, <, etc.)
- "correct answers" for mixed-type comparisons vs. blowing out
I believe that although they are related, they are orthogonal. So I
will discuss them separately.
I don't think that you really want the coercion rules for operations to
prefer rational arithmetic to floating-point. Consider that (+ x 1)
will leave you with a rational result. Remember that rational
canonicalization means you can't distinguish a "ratio" 1/1 from an
integer 1. You'd have to be incredibly compulsive to keep your
computations from consing ratios and taking forever.
The reason we keep floating-point around is to do computations
efficiently. By introducing a float, you're saying, "I know the answer
might not be exactly correct, but I know what I'm doing -- just give me
an answer, and give it to me fast." [-: I do know that a lot of people
who use floating-point don't know what they're doing. But we should
pretend they do. :-]
You might want comparisons to be done rationally, although pretending
that 0.0 is the same as 0 seems foolish to me. And the efficiency issue
remains, since (< x 1) would most likely cons you a ratio of bigna.
I do agree that you'd like to get answers to any comparison that doesn't
involve NaNs. But that's possible even with the current CLtL coercion
rules. In the next release of the Symbolics system, mixed-type
comparisons are done in floating-point ala CLtL, but over- and underflow
are accounted for so that "correct" answers are always given.
∂24-Jan-86 1946 FAHLMAN@C.CS.CMU.EDU comparisons between floats and ratios
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 Jan 86 19:45:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 24 Jan 86 22:17:03-EST
Date: Fri, 24 Jan 1986 21:41 EST
Message-ID: <FAHLMAN.12177928890.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: comparisons between floats and ratios
In-reply-to: Msg of 24 Jan 1986 19:20-EST from Robert A. Cassels <Cassels at TENEX.SCRC.Symbolics.COM>
The phrase that Fateman spotted on page 194 occurs in the middle of a
discussion of FLOATING-POINT contagion rules. I think there is no
suggestion, explicit or implicit, that as things currently stand this
rule is meant to cover other kinds of numbers.
Of course, it is legitimate to propose that we consider extending the
rule in this way. After thinking about it a bit, I agree with Cassels
on this. Coercing a float/rational operation to produce a rational is
certainly going to lead to a lot of needless inefficiency and confusion,
just to get rid of a paradox that most of us don't view as being
paradoxical at all. And it just doesn't seem reasonable to me -- it's a
bit like trying to restore the number's virginity.
-- Scott
∂24-Jan-86 2101 fateman@dali.berkeley.edu Re: comparisons between floats and ratios
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 24 Jan 86 21:00:46 PST
Received: by ucbvax.berkeley.edu (5.44/1.8)
id AA04759; Fri, 24 Jan 86 21:00:59 PST
Received: by dali.berkeley.edu (5.44/5.16)
id AA05647; Fri, 24 Jan 86 21:00:53 PST
Date: Fri, 24 Jan 86 21:00:53 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601250500.AA05647@dali.berkeley.edu>
To: Fahlman@c.cs.cmu.edu, common-lisp@su-ai.arpa
Subject: Re: comparisons between floats and ratios
Subject: Re: comparisons between floats and ratios
I remain unconvinced, and a private note from Cassels also didn't
help. (My mailing system was unable to send to Cassels individually,
so here is a simplified response )
consider (/ (expt 10 68) 1.0E38) .
The numerator overflows when you convert to floating point.
The quotient is representable. I think that CL should err on the
side of slow&correct.
While Cassel's solution to comparisons, by looking at overflows should be ok,
it won't solve the above problem.
Anyone who writes (+ x 1) when he means (+ x 1.0) can be warned or should
pay the cost. Anyone who wants to AVOID conversions to mathematically
reliable answers can easily insist on sloppy floats.
∂26-Jan-86 1324 Moon@SCRC-STONY-BROOK.ARPA Re: comparisons between floats and ratios
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jan 86 13:24:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 401792; Sun 26-Jan-86 16:23:56-EST
Date: Sun, 26 Jan 86 16:24 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: comparisons between floats and ratios
To: Richard Fateman <fateman@dali.berkeley.edu>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8601250500.AA05647@dali.berkeley.edu>
Message-ID: <860126162435.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 24 Jan 86 21:00:53 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
I remain unconvinced, and a private note from Cassels also didn't
help. (My mailing system was unable to send to Cassels individually,
so here is a simplified response )
consider (/ (expt 10 68) 1.0E38) .
The numerator overflows when you convert to floating point.
The quotient is representable. I think that CL should err on the
side of slow&correct.
How is this example different from (/ (* 1.0e34 1.0e34) 1.0E38) ?
If you want to campaign against the widespread misimpression that floating
point is foolproof way to do numerical calculations, that's a fine thing, but
I think this is the wrong mailing list.
∂26-Jan-86 1413 fateman@dali.berkeley.edu more boring-to-most-people floating point stuff
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 26 Jan 86 14:13:22 PST
Received: by ucbvax.berkeley.edu (5.44/1.8)
id AA01884; Sun, 26 Jan 86 14:13:36 PST
Received: by dali.berkeley.edu (5.44/5.16)
id AA19482; Sun, 26 Jan 86 14:13:29 PST
Date: Sun, 26 Jan 86 14:13:29 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601262213.AA19482@dali.berkeley.edu>
To: Moon@scrc-stony-brook.arpa
Subject: more boring-to-most-people floating point stuff
Cc: common-lisp@su-ai.arpa
The example (/ (expt 10 68) 1.0e38) is illustrating
( <operator> <number-type-1> <number-type-2> ) whereas
(/ (* 1.0e34 1.0e34) 1.0e38) is illustrating (recursively)
(<operator> <number-type-1> <number-type-1>) .
Only when you combine two number types, one majorizing the other,
do you face this issue. The intent when combining different precisions
(and ranges) within floats is clear. You coerce to the longer precision
because it is likely to give you the right answer. Not the fastest.
A reasonable extension of this is if you mix floats with even longer
precision numbers (i.e., rational), you convert to rational, because it
gives you the right answer, not the fastest.
You can, of course, promote the notion that "anything goes" as soon as exact
and approximate numeric types are mixed, or claim that it would be too
costly to do the right thing.
To say this is the wrong forum for this is to
appear at odds with the space devoted to this
and other numeric data types in the language specification.
∂26-Jan-86 1920 GJC@MC.LCS.MIT.EDU precision vs more information
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Jan 86 19:20:01 PST
Date: Sun, 26 Jan 86 22:20:54 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: precision vs more information
To: fateman@DALI.BERKELEY.EDU
cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Sun 26 Jan 86 14:13:29 PST from fateman at dali.berkeley.edu (Richard Fateman)
Message-ID: <[MC.LCS.MIT.EDU].796884.860126.GJC>
If you go from a floating point number to a ratio you lose information,
the information that the number is an approximation. Exactly how
much of an approximation is hard to tell of course because it depends
on the computational history of the quantity. But the fact that it is
a floating point number can be dangerous information to loose so easily.
This about this:
(defun s (t)
(* 1/2 g (↑ t 2)))
The 1/2 has been introduced do to a process of symbolic integration.
Why should it affect the form of the answer to a formula?
Returning a floating point number tells you that the result might
not be the right answer. But with rational arithmetic you can be
sure of getting simply meaningful mathematic results from your
formuli.
∂26-Jan-86 1939 KSH@MC.LCS.MIT.EDU
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Jan 86 19:38:58 PST
Date: Sun, 26 Jan 86 22:39:53 EST
From: Kjeld Hvatum <KSH@MC.LCS.MIT.EDU>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].796915.860126.KSH>
From: Steve Bacher (CSDL)
To: Robert Elton Maas
Subject: Compiler side effects lossage
It sounds like your compiler used the C... properties exclusively,
refusing to use normal propertis {sic} even when the C... property
didn't exist.
I can't speak for Charles Hedrick or his compiler, but I do know that
this problem can definitely occur even when the property masking you
describe is in use. Consider the case of a DEFMACRO which references
a function defined via DEFUN (or DEFMACRO, etc.) in the same file.
If the compiler dutifully assigns a CMACRO or CFUNCTION property for
the function in question, then invokes MACROEXPAND on the macro
definition associated with the first DEFMACRO, you should expect to
run into trouble if your macroexpander uses the standard evaluator,
since that one, as described, WILL NOT find compiler-generated defs
like CFUNCTION. Now, unless you want to rewrite the evaluator for
the compiler to process Cfrobs, you can't get around this.
The user will simply have to wrap an (eval-when (compile ...))
around the ancillary DEFstuff - and this implies that the way the
compiler treats DEFUN, DEFMACRO, etc. *cannot* be desribed as a case
of an implicit (eval-when (compile)). Which means that I must take
issue with the earlier statement of Rob MacLachlan's that there's no
way to override the implicit eval-whenitude of DEFUN et al.
Lest you believe that this is all idle speculation and windbagging,
let me point out that this is essentially how I have structured my
LISP compiler, and this problem does come up despite the best of
intentions. (Another screw case is defining SETF methods.)
- Steve Bacher
∂27-Jan-86 0543 GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU comparisons between floats and ratios
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jan 86 05:43:29 PST
Date: Mon 27 Jan 86 08:42:53-EST
From: "Gail Zacharias" <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: comparisons between floats and ratios
To: common-lisp@SU-AI.ARPA
Message-ID: <12178573608.22.GZ@OZ.AI.MIT.EDU>
Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
would overflow? If so, there should at least be some way to tell ahead of time
if that's going to happen, for people who want to write a more careful
comparison routine. The only way I can figure out of doing this now is
(> a-ratio (rational most-positive-xx-float)). Consing up a bignum
representation of the largest float seems like a high price to pay for being
careful.
Since most floating point implementations can (internally at least) represent
infinity, it shouldn't cause a great loss of efficiency to require that this
case return T.
A not-entirely-unrelated question: What kind of rounding is FLOAT supposed
to do?
-------
∂27-Jan-86 0644 RAM@C.CS.CMU.EDU Compiler side effects lossage
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jan 86 06:44:30 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 27 Jan 86 09:44:46-EST
Date: Mon, 27 Jan 1986 09:44 EST
Message-ID: <RAM.12178584864.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Compiler side effects lossage
Cc: Kjeld Hvatum <KSH@MC.LCS.MIT.EDU>
In-reply-to: Msg of 26 Jan 1986 22:39-EST from Kjeld Hvatum <KSH at MC.LCS.MIT.EDU>
From: Steve Bacher (CSDL)
To: Robert Elton Maas
Subject: Compiler side effects lossage
The user will simply have to wrap an (eval-when (compile ...))
around the ancillary DEFstuff - and this implies that the way the
compiler treats DEFUN, DEFMACRO, etc. *cannot* be desribed as a case
of an implicit (eval-when (compile)). Which means that I must take
issue with the earlier statement of Rob MacLachlan's that there's no
way to override the implicit eval-whenitude of DEFUN et al.
Actually this is exactly my point. I was arguing that such forms
should not be considered to have an implicit (eval-when (compile)); if
they really did there would be no way to inhibit the compile-time
evaluation. This is more a statement about the language which should
be used in the definition than it is about the semantics of Common Lisp.
Rob
∂27-Jan-86 0737 FAHLMAN@C.CS.CMU.EDU comparisons between floats and ratios
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jan 86 07:37:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jan 86 10:37:58-EST
Date: Mon, 27 Jan 1986 10:37 EST
Message-ID: <FAHLMAN.12178594550.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gail Zacharias <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: comparisons between floats and ratios
In-reply-to: Msg of 27 Jan 1986 08:42-EST from Gail Zacharias <GZ%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
would overflow? If so, there should at least be some way to tell ahead of time
if that's going to happen, for people who want to write a more careful
comparison routine.
Sounds like a job for the error system (a proposal for which KMP is
supposed to have ready soon). Better to intercept this rare overflow
problem when it occurs, and when you actually care, than to slow down
the universe by trying to prevent it.
∂27-Jan-86 0742 FAHLMAN@C.CS.CMU.EDU comparisons between floats and ratios
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jan 86 07:41:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jan 86 10:42:18-EST
Date: Mon, 27 Jan 1986 10:42 EST
Message-ID: <FAHLMAN.12178595334.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gail Zacharias <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: comparisons between floats and ratios
In-reply-to: Msg of 27 Jan 1986 08:42-EST from Gail Zacharias <GZ%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
A not-entirely-unrelated question: What kind of rounding is FLOAT supposed
to do?
I think that the GOAL is to produce the closest approximation to the
ratio that is possible in a given floating-point format. That's what
implementors should shoot for. Whether it makes sense to REQUIRE this
in the very last bit is less clear. I don't think I've ever seen a
floating-point package that got this right all the time.
-- Scott
∂27-Jan-86 0812 DCP@SCRC-VALLECITO.ARPA comparisons between floats and ratios
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 27 Jan 86 08:11:03 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 79954; Mon 27-Jan-86 11:10:26-EST
Date: Mon, 27 Jan 86 11:16 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: comparisons between floats and ratios
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Gail Zacharias <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12178594550.BABYL@C.CS.CMU.EDU>
Message-ID: <860127111609.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 27 Jan 1986 10:37 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
would overflow? If so, there should at least be some way to tell ahead of time
if that's going to happen, for people who want to write a more careful
comparison routine.
Sounds like a job for the error system (a proposal for which KMP is
supposed to have ready soon). Better to intercept this rare overflow
problem when it occurs, and when you actually care, than to slow down
the universe by trying to prevent it.
There are two places to put the condition-case/bind (or whatever the KMP
equivalent is). One is in the application program, the other is in the
system code that does the comparision.
Putting it in the application program will look like Common Lisp has a
wart that numeric comparisons need special help sometimes.
Putting it in the system code would probably slow it down as much as
doing the check. The system code would probably look like (already
checked that both are positive):
(block nil
(> (condition-case ()
(float a-rational a-float)
(<overflow> (return t))
(<underflow> (return nil)))
a-float))
This points up a problem with putting it in the application program: If
overflow is signalled, how does the application figure out what the
intent was? It might be hard to figure out that (float a-rational a-float),
which is where the error happened, was being used for >.
∂27-Jan-86 1153 fateman@dali.berkeley.edu precision, accuracy, and floating conversion (GJC's comment)
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 27 Jan 86 11:52:52 PST
Received: by ucbvax.berkeley.edu (5.44/1.8)
id AA19106; Mon, 27 Jan 86 11:52:45 PST
Received: by dali.berkeley.edu (5.44/5.16)
id AA06514; Mon, 27 Jan 86 11:52:37 PST
Date: Mon, 27 Jan 86 11:52:37 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601271952.AA06514@dali.berkeley.edu>
To: common-lisp@su-ai.arpa
Subject: precision, accuracy, and floating conversion (GJC's comment)
GJC's view that a floating point number x means an interval
[x-epsilon,x+epsilon] for some unknown epsilon, is not
treated kindly in most of the current thinking about floating
point arithmetic. To be consistent here, you should also propose
that in combining floating point numbers, the SHORTEST precision
should be used, because that would indicate that the answer is
particularly uncertain.
As for GJC's example, if I understand it, you want a floating point
number so you can return (the float (* 1/2 ...)) or (* (the float 1/2) ...)
∂27-Jan-86 1417 gls@THINK-AQUINAS.ARPA precision, accuracy, and floating conversion (GJC's comment)
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 27 Jan 86 14:17:22 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 27 Jan 86 17:17:37 est
Date: Mon, 27 Jan 86 17:18 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: precision, accuracy, and floating conversion (GJC's comment)
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8601271952.AA06514@dali.berkeley.edu>
Message-Id: <860127171840.5.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Mon, 27 Jan 86 11:52:37 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
...
As for GJC's example, if I understand it, you want a floating point
number so you can return (the float (* 1/2 ...)) or (* (the float 1/2) ...)
Technical nit: I think these expressions should be
(float (* 1/2 ...)) or (* (float 1/2) ...)
to be correct. On the other hand, I think that GJC really wanted was
to write a constant at the bottom of the coercion chain so that the type
of the argument would determine the type of the answer. Hence
(coerce (* 1/2 ...) (type-of arg)) or (* (coerce 1/2 (type-of arg)) ...)
would do.
∂27-Jan-86 1449 gls@THINK-AQUINAS.ARPA Comparing float to rational
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 27 Jan 86 14:49:31 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 27 Jan 86 17:49:27 est
Date: Mon, 27 Jan 86 17:50 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Comparing float to rational
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860127175030.6.GLS@THINK-JEHOSEPHAT.ARPA>
I thinm that Fateman has raised a valid issue that deserves discussion.
Right now the Common Lisp book does seem to specify quite clearly (page
194) that for comparison as well as "combining" of a rational with a
float, the rational shall be converted to a float of the same format.
Evidence on the other side of the question is the remark that for
MAX and MIN, if the largest (resp. smallest) argument is a rational
then the returned result may be a rational even though the argument
is a float.
I think there is a lot to be said for requiring comparison between a
rational and a float always to work and not to overflow. I think there
is much less to be said in the case of addition, but I am on less solid
ground here. What is FORTRAN's position on this? In FORTRAN when an
integer meets a float, the integer gets converted to a float. I can't
find my copy of the FORTRAN '77 standard just this minute, but I don't
recall anything in the standard requiring the range of a float to be as
large as that of an integer (granted that for an integer to exceed the
range of a float would be considered unusual in that culture).
I also reject the notion that a floating-point number is really an
interval (though I'm not sure GJC implied this directly). However, I do
think it is reasonable to consider floating-point numbers to be
approximations--at least, once the inexact flag gets set. (It seems to
me, by the way, that if bits were free it would be more sensible to have
an inexact bit in every value rather than a single global flag; but bits
are not free and the 754 committee was having to sweat as it was to cram
everything into 32 bits.) One strives for a reasonable economic balance
between accuracy, speed, and ease of understanding. In the case of
comparisons, it is not too difficult to be completely accurate, and
doing so makes it much easier to understand. That's as far as I go with
confidence. The issue for addition or multiplication is not so clear,
because the speed costs are not clear (they can cascade). This is a
reasonable matter for discussion.
--Guy
∂27-Jan-86 1608 GJC@MC.LCS.MIT.EDU precision, accuracy, and floating conversion (GJC's comment)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jan 86 16:08:46 PST
Date: Mon, 27 Jan 86 19:09:33 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: precision, accuracy, and floating conversion (GJC's comment)
To: fateman@DALI.BERKELEY.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 27 Jan 86 11:52:37 PST from fateman at dali.berkeley.edu (Richard Fateman)
Message-ID: <[MC.LCS.MIT.EDU].798122.860127.GJC>
Quote RJF:
"GJC's view that a floating point number x means an interval
[x-epsilon,x+epsilon] for some unknown epsilon, is not ..."
Quote GJC:
"...that is *not* GJC's view"
Quote GJC again (sigh):
"'nuff said, but what about the PI bit? If the PI bit is set then
floating point numbers are to be taken as a multiplier of PI. If the E bit
then as a multiplier of (EXP 1)..."
∂27-Jan-86 1854 ME :capitalize in *print-case*
To: common-lisp@SU-AI.ARPA
CC: ME@SU-AI.ARPA
CLtL says that lowercase letters in print names are always printed in
lowercase, and that *print-case* controls the printing of uppercase.
This implies that with *print-case* set to :CAPITALIZE, the symbol |aBCD|
should be printed as |abcd|. This is of course not a capitalized word,
and I've seen at least one Common Lisp implementation that prints this
symbol as |Abcd|, thus violating the claim that "lowercase letters are
always printed in lowercase".
So which way should it be with :CAPITALIZE? Should it really capitalize
or should lowercase letters always be printed in lowercase?
∂27-Jan-86 2050 FAHLMAN@C.CS.CMU.EDU :capitalize in *print-case*
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jan 86 20:50:16 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jan 86 23:50:53-EST
Date: Mon, 27 Jan 1986 23:50 EST
Message-ID: <FAHLMAN.12178738898.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Martin Frost <ME@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: :capitalize in *print-case*
In-reply-to: Msg of 27 Jan 1986 21:54-EST from Martin Frost <ME at SU-AI.ARPA>
I think that the manual means what it says here: lower-case characters
don't get touched, regardless of the setting of this switch. The theory
is that most symbol print names end up in all-upper-case internally, and
the *print-case* flags control how you want to see those. If the user
has taken special trouble to get a lower-case character into a symbol's
print name, we assume that he really wants to see a lower-case character
there. This is all pretty ugly, but seemed like the thing to do at the
time; it's something of a holdover from the bad old days when the only
way to get a character string was to make it the print-name of a symbol.
-- Scott
∂27-Jan-86 2110 Moon@SCRC-STONY-BROOK.ARPA :capitalize in *print-case*
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Jan 86 21:09:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403054; Tue 28-Jan-86 00:08:06-EST
Date: Tue, 28 Jan 86 00:08 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: :capitalize in *print-case*
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Martin Frost <ME@SU-AI.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12178738898.BABYL@C.CS.CMU.EDU>
Message-ID: <860128000857.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 27 Jan 1986 23:50 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think that the manual means what it says here: lower-case characters
don't get touched, regardless of the setting of this switch.
I agree. Note that the manual clearly states that this switch does not
affect printing when vertical bar syntax is used and that internally
lowercase characters are printed in lowercase with an escape (backslash
or vertical bar).
An implementation where *print-case* changes what appears inside vertical
bars is incorrect.
∂27-Jan-86 2308 fateman@dali.berkeley.edu IEEE float co-processors
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 27 Jan 86 23:08:04 PST
Received: by ucbvax.berkeley.edu (5.44/1.8)
id AA00269; Mon, 27 Jan 86 23:08:29 PST
Received: by dali.berkeley.edu (5.44/5.16)
id AA04790; Mon, 27 Jan 86 23:08:19 PST
Date: Mon, 27 Jan 86 23:08:19 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601280708.AA04790@dali.berkeley.edu>
To: common-lisp@su-ai.arpa
Subject: IEEE float co-processors
Cc: fateman@dali.berkeley.edu
in CLtL p193-194 it is stated that an operation combining a short float
with a long results in a long. Presumably if you combine
a short + a single you get a single. But how precise is the intermediate
arithmetic?
Is it OK to do the arithmetic in "long", or MUST you do the arithmetic
no more precisely and with no larger range than "single"?
Consider any of a number of existing and proposed
co-processors in which all arithmetic is in fact done in, say, 80 bit units.
A single * short * short then stored to a single
would be done by converting each argument to a long, multiplying
and rounding to single. This is faster than any other method using most
such chips.
Unfortunately, it might get an answer better than that prescribed by following
CLtL strictly. Using the method on p 194, one can come up with problems
where intermediate arithmetic done in single might overflow, underflow,
or lose precision disasterously, (or all of these) before the final,
exactly-single-representable answer is computed.
I believe the standard should allow the processor to perform all floating
point arithmetic computations in highest precision, and not require
multiple conversions (from short to single to double to long).
The paragraph which allows rearrangement or conversion to the longest
format IN THE EXPRESSION is not flexible enough to quite allow this.
∂28-Jan-86 0331 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Spelling correction
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Jan 86 03:31:11 PST
Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 28 Jan 86 06:30-EST
Date: Tue, 28 Jan 86 06:29 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Spelling correction
To: Fahlman@C.CS.CMU.EDU, BACH@SU-SCORE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12177538793.BABYL@C.CS.CMU.EDU>
Message-ID: <860128062939.3.CFRY@DUANE.AI.MIT.EDU>
Spelling correction would be less necessary in
Common Lisp if the names of certain functions were
easier to spell.
For example:
rplaca
cddadr
nsublis
svref
sqrt
hash-table [the type, includes dash]
readtable [the type, no dash]
exp, expt
dpb
Fixing the source of common spelling errors would be
more profitable than adding heuristic patches like
spelling correctors.
Since the above examples are set in concrete,
a yellow pages spelling corrector may make it possible
for a part-time hacker [whose voice isn't heard on this mailing list]
to survive in the unnecessarily complex CL environment.
∂28-Jan-86 0452 GJC@MC.LCS.MIT.EDU Spelling correction
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Jan 86 04:52:19 PST
Date: Tue, 28 Jan 86 07:53:17 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Spelling correction
To: cfry@OZ.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA, BACH@SU-SCORE.ARPA,
Fahlman@C.CS.CMU.EDU
In-reply-to: Msg of Tue 28 Jan 86 06:29 EST from Christopher Fry <cfry at OZ.AI.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].798777.860128.GJC>
In the LMI system we have a spelling correction function that evolved
as MIDAS (ITS SPELL) -> C (by Pace Willison) -> ZetaLisp (again Pace).
It has only been used for META-$ in Zmacs so far; but maybe somebody
would be willing to CL'ify it and perhaps try hooking it into the
DWIMIFY-PACKAGE hooks that are in various error handlers.
∂28-Jan-86 0545 FAHLMAN@C.CS.CMU.EDU Spelling correction
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Jan 86 05:45:12 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Jan 86 08:46:01-EST
Date: Tue, 28 Jan 1986 08:45 EST
Message-ID: <FAHLMAN.12178836317.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Spelling correction
In-reply-to: Msg of 28 Jan 1986 06:29-EST from Christopher Fry <cfry at OZ.AI.MIT.EDU>
In reply to Christopher Fry <cfry at OZ.AI.MIT.EDU>
Sounds to me like you want a synonym facility rather than spelling
correction. Then you can spell things however you like.
For Hemlock users, we've now got word abbrev mode in, and people are
experimenting with various versions of Lisp-mode symbol-completion.
-- Scott
∂28-Jan-86 0555 FAHLMAN@C.CS.CMU.EDU IEEE float co-processors
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Jan 86 05:55:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Jan 86 08:56:35-EST
Date: Tue, 28 Jan 1986 08:56 EST
Message-ID: <FAHLMAN.12178838237.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: fateman@λdali.berkeley.edu (Richard Fateman)λ
Cc: common-lisp@SU-AI.ARPA
Subject: IEEE float co-processors
In-reply-to: Msg of 28 Jan 1986 02:08-EST from fateman at dali.berkeley.edu (Richard Fateman)
I believe the standard should allow the processor to perform all floating
point arithmetic computations in highest precision, and not require
multiple conversions (from short to single to double to long).
The paragraph which allows rearrangement or conversion to the longest
format IN THE EXPRESSION is not flexible enough to quite allow this.
This sounds like a good proposal, and it wouldn't break anyone's code to
implement it. I think that all we need is a clarification that says
that a compiler is allowed to do whatever it wants to in handling
the precision of intermediate arithmetic results, as long as any outputs
finally accessible to the user are of the specified type and as long as
precision is at least as good as you would get by doing the obvious
coercions at each step.
My only concern is that the interpreter would probably be stuck with
doing the coercions at each step, and therefore might get a slightly
different (less precise) answer than the compiler would come up with.
Would that bother anyone? (Not me, but I only look at the first two
digits anyway...)
-- Scott
∂28-Jan-86 0728 csi!meehan%UUCP@YALE.ARPA DEFUN inside LET
Received: from YALE-CHEOPS.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 07:28:07 PST
Received: by yale-cheops.YALE.ARPA; Tue, 28 Jan 86 10:15:42 est
Message-Id: <8601281515.AA16516@yale-cheops.YALE.ARPA>
Received: by CSI-RING; Tue, 28 Jan 86 10:06:27 est
Date: Tue, 28 Jan 86 10:06:27 est
From: James R. Meehan <csi!meehan%UUCP@YALE.ARPA>
To: common-lisp@su-ai.arpa
Subject: DEFUN inside LET
I remember seeing some mail on this topic, but I don't remember
whether there was a consensus. Is Common Lisp supposed to support
DEFUN inside LET? I know you can always write
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...))
to get much the same effect, but that's awkward.
∂28-Jan-86 0748 DCP@SCRC-STONY-BROOK.ARPA IEEE float co-processors
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 07:47:08 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403255; Tue 28-Jan-86 10:39:42-EST
Date: Tue, 28 Jan 86 10:45 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: IEEE float co-processors
To: Richard Fateman <fateman@dali.berkeley.edu>,
Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <8601280708.AA04790@dali.berkeley.edu>,
<FAHLMAN.12178838237.BABYL@C.CS.CMU.EDU>
Message-ID: <860128104531.4.DCP@NEPONSET.SCRC.Symbolics.COM>
I think I agree with what you two are talking about. It is critical
that the answer be of the correct type. We (Symbolics) used to have a
proceed option such that if a single float computation overflowed, the
user could continue using double floats. We got rid of that after we
realized that was tempting users to believe they had more accuracy than
they actually had. It all goes back to: If you are going to use
floating point, you better know what you are doing.
∂28-Jan-86 1108 Moon@SCRC-STONY-BROOK.ARPA IEEE float co-processors
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 11:06:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403454; Tue 28-Jan-86 13:47:43-EST
Date: Tue, 28 Jan 86 13:48 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: IEEE float co-processors
To: Richard Fateman <fateman@dali.berkeley.edu>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8601280708.AA04790@dali.berkeley.edu>
Message-ID: <860128134840.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Note that on page 16 of the Common Lisp manual, the language is carefully
defined not to require any particular floating-point format or arithmetic.
For the same reasons that the language does not require adherence to the
IEEE floating-point standard (or any other), I think it makes sense for
the language not to require any particular precision for intermediate
results. Defining floating point more precisely would limit portability
to different pieces of hardware, or else would limit efficiency, and if
efficiency is not a concern, why use floating point at all?
∂28-Jan-86 1250 Cassels@SCRC-STONY-BROOK.ARPA Comparing float to rational
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 12:49:36 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403553; Tue 28-Jan-86 14:54:13-EST
Date: Tue, 28 Jan 86 14:56 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: Comparing float to rational
To: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860127175030.6.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <860128145652.9.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>
Date: Mon, 27 Jan 86 17:50 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
I thinm that Fateman has raised a valid issue that deserves discussion.
Right now the Common Lisp book does seem to specify quite clearly (page
194) that for comparison as well as "combining" of a rational with a
float, the rational shall be converted to a float of the same format.
Evidence on the other side of the question is the remark that for
MAX and MIN, if the largest (resp. smallest) argument is a rational
then the returned result may be a rational even though the argument
is a float.
I think there is a lot to be said for requiring comparison between a
rational and a float always to work and not to overflow. I think there
is much less to be said in the case of addition, but I am on less solid
ground here. What is FORTRAN's position on this? In FORTRAN when an
integer meets a float, the integer gets converted to a float. I can't
find my copy of the FORTRAN '77 standard just this minute, but I don't
recall anything in the standard requiring the range of a float to be as
large as that of an integer (granted that for an integer to exceed the
range of a float would be considered unusual in that culture).
Right. In the land of Fortran machines, integers can't overflow when
converted to floats. But, speaking of Fortran, perhaps overflow
considerations are where the coercion rules came from -- integers don't
overflow when converted to singles, and singles don't overflow when
converted to doubles. Now that we have bignums, the ground rules are
different and we can rethink the rules.
I also reject the notion that a floating-point number is really an
interval (though I'm not sure GJC implied this directly). However, I do
think it is reasonable to consider floating-point numbers to be
approximations--at least, once the inexact flag gets set. (It seems to
me, by the way, that if bits were free it would be more sensible to have
an inexact bit in every value rather than a single global flag; but bits
are not free and the 754 committee was having to sweat as it was to cram
everything into 32 bits.) One strives for a reasonable economic balance
between accuracy, speed, and ease of understanding. In the case of
comparisons, it is not too difficult to be completely accurate, and
doing so makes it much easier to understand. That's as far as I go with
confidence. The issue for addition or multiplication is not so clear,
because the speed costs are not clear (they can cascade). This is a
reasonable matter for discussion.
--Guy
∂28-Jan-86 1256 Cassels@SCRC-STONY-BROOK.ARPA comparisons between floats and ratios
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 12:56:44 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403567; Tue 28-Jan-86 15:04:10-EST
Date: Tue, 28 Jan 86 15:06 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: comparisons between floats and ratios
To: DCP@SCRC-QUABBIN.ARPA, Fahlman@C.CS.CMU.EDU,
GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860127111609.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <860128150652.0.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>
Date: Mon, 27 Jan 86 11:16 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Date: Mon, 27 Jan 1986 10:37 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
would overflow? If so, there should at least be some way to tell ahead of time
if that's going to happen, for people who want to write a more careful
comparison routine.
Sounds like a job for the error system (a proposal for which KMP is
supposed to have ready soon). Better to intercept this rare overflow
problem when it occurs, and when you actually care, than to slow down
the universe by trying to prevent it.
There are two places to put the condition-case/bind (or whatever the KMP
equivalent is). One is in the application program, the other is in the
system code that does the comparision.
Putting it in the application program will look like Common Lisp has a
wart that numeric comparisons need special help sometimes.
Putting it in the system code would probably slow it down as much as
doing the check. The system code would probably look like (already
checked that both are positive):
(block nil
(> (condition-case ()
(float a-rational a-float)
(<overflow> (return t))
(<underflow> (return nil)))
a-float))
This points up a problem with putting it in the application program: If
overflow is signalled, how does the application figure out what the
intent was? It might be hard to figure out that (float a-rational a-float),
which is where the error happened, was being used for >.
Ack! Even though we have an error system, I didn't consider using it
for this particular application. I used the IEEE-required ability to
turn off overflow traps: [simplified for presentation]
(defnumop < ((x float) (y bignum))
(if (infinite x) ; + or - infinity
(minusp x)
(without-floating-overflow-traps
(< x (float y x)))))
∂28-Jan-86 1309 Cassels@SCRC-STONY-BROOK.ARPA comparisons between floats and ratios
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 13:08:50 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403573; Tue 28-Jan-86 15:06:29-EST
Date: Tue, 28 Jan 86 15:09 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: comparisons between floats and ratios
To: Fahlman@C.CS.CMU.EDU, GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12178595334.BABYL@C.CS.CMU.EDU>
Message-ID: <860128150911.1.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>
Date: Mon, 27 Jan 1986 10:42 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
A not-entirely-unrelated question: What kind of rounding is FLOAT supposed
to do?
I think that the GOAL is to produce the closest approximation to the
ratio that is possible in a given floating-point format. That's what
implementors should shoot for. Whether it makes sense to REQUIRE this
in the very last bit is less clear. I don't think I've ever seen a
floating-point package that got this right all the time.
You haven't looked at your 36xx lately, then.
-- Scott
∂28-Jan-86 1314 lab@rochester.arpa IEEE float co-processors
Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 13:13:37 PST
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA00446 (4.12u); Tue, 28 Jan 86 16:13:29 est
Received: by ur-seneca.rochester.arpa id AA01690 (4.12v); Tue, 28 Jan 86 15:12:49 est
Message-Id: <8601282012.1690@ur-seneca.rochester.arpa>
Date: Tue, 28 Jan 86 15:12:49 est
From: Lab Manager(Brad Miller) <lab@rochester.arpa>
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: David A. Moon's message of Tue, 28 Jan 86 13:48 EST
Subject: IEEE float co-processors
I have not been thrilled with this ongoing meandering about floating
point, but I'd like to take exception to your statement about leaving
intermediate result precision unspecified. It would be nice if a
program working on one machine also worked on another. Surely that is
what portability is supposed to insure, not that the language is so
general that any floating point result is OK. Make everything BIGNUM
and forget it.
∂28-Jan-86 1500 REM@IMSSS Rebuttal to incorrect statement of portability definition
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-28 14:59:18 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1986 January 28 14:56:44 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS> (this host known locally only)
To:lab@rochester.arpa
CC:COMMON-LISP@SU-AI.ARPA
Subject:Rebuttal to incorrect statement of portability definition
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA
L> Date: Tue, 28 Jan 86 15:12:49 est
L> From: Lab Manager(Brad Miller) <lab@rochester.arpa>
L> It would be nice if a program working on one machine also worked on
L> another. Surely that is what portability is supposed to insure, not
L> that the language is so general that any floating point result is OK.
The contrapositive is that if it fails on another then it also fails
on the one. I.e. nobody is allowed to make any improvements beyond the
minimal implementation. Nobody is allowed to make private enhancements
to the language, such as a window system etc. I disapprove.
The correct statement, in my opinion, is that any program which
restricts itself to features and capabilities as defined in CLtL will
run on any machine, but programs are permitted to take advantage of
nonportable features at the expense of no longer being portable. Thus
in the case at hand, programs that rely only on the minimal accuracy
of minimal results will be portable, runnable on all CL
implementations, but it is possible that some programs may take
advantage of extra accuracy available only on certain machines and
those programs will not be portable. The programmer should attempt to
determine whether the program is truly portable or not, although
sometimes that may be difficult to determine without actually trying
it on other machines (computer programming is still an experimental
science). It may be desirable to have a flag that disables use of
extended precision co-processors in order to test portability on a
single machine, but it should be legal to switch that flag to
machine-dependent maximum-precision mode at times.
∂28-Jan-86 1526 Moon@SCRC-STONY-BROOK.ARPA IEEE float co-processors
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 15:26:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403727; Tue 28-Jan-86 17:32:17-EST
Date: Tue, 28 Jan 86 17:33 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: IEEE float co-processors
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8601282012.1690@ur-seneca.rochester.arpa>
Message-ID: <860128173314.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 28 Jan 86 15:12:49 est
From: Lab Manager(Brad Miller) <lab@rochester.arpa>
I have not been thrilled with this ongoing meandering about floating
point, but I'd like to take exception to your statement about leaving
intermediate result precision unspecified. It would be nice if a
program working on one machine also worked on another. Surely that is
what portability is supposed to insure, not that the language is so
general that any floating point result is OK.
Well, you see, there are two conflicting goals here. It would be nice
for programs to be portable. It would also be nice for the Common Lisp
community not to have to take on the job of forcing IBM and DEC to agree
on a common format and semantics for floating-point arithmetic.
What we have done is to provide some features for finding out the
characteristics of floating-point arithmetic in a particular implementation.
This may be only a half measure, but it may also be the best we can do.
Taking off my language designer hat and putting on my manufacturer hat, of
course the system my company sells conforms to the IEEE standard and otherwise
makes an effort to provide reasonable, consistent, and standardized
floating-point semantics. Some other manufacturers do so as well. But I
don't think we want to forbid Common Lisp to be implemented on hardware that,
for whatever reason, has different ideas about how floating-point should work.
I'm going to try not to send any more mail on this subject.
∂28-Jan-86 1803 Cassels@SCRC-STONY-BROOK.ARPA more boring-to-most-people floating point stuff
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86 18:03:28 PST
Received: from WAIKATO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403885; Tue 28-Jan-86 20:49:51-EST
Received: from CUYAHOGA.SCRC.Symbolics.COM by WAIKATO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 150379; Tue 28-Jan-86 20:51:24-EST
Date: Tue, 28 Jan 86 20:52 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: more boring-to-most-people floating point stuff
To: fateman@dali.berkeley.edu, Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8601262213.AA19482@dali.berkeley.edu>
Message-ID: <860128205234.4.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>
Date: Sun, 26 Jan 86 14:13:29 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
The example (/ (expt 10 68) 1.0e38) is illustrating
( <operator> <number-type-1> <number-type-2> ) whereas
(/ (* 1.0e34 1.0e34) 1.0e38) is illustrating (recursively)
(<operator> <number-type-1> <number-type-1>) .
Only when you combine two number types, one majorizing the other,
do you face this issue. The intent when combining different precisions
(and ranges) within floats is clear. You coerce to the longer precision
because it is likely to give you the right answer. Not the fastest.
A reasonable extension of this is if you mix floats with even longer
precision numbers (i.e., rational), you convert to rational, because it
gives you the right answer, not the fastest.
You can, of course, promote the notion that "anything goes" as soon as exact
and approximate numeric types are mixed, or claim that it would be too
costly to do the right thing.
I agree it's a question of what's right, not what's costly. [Now that
we have the EGC, we don't worry so much about consing.] I think my
earlier statements about efficiency were really trying to get at my last
point below about generic numeric functions. (Although I would like my
generic functions to be as efficient as possible.)
To say this is the wrong forum for this is to
appear at odds with the space devoted to this
and other numeric data types in the language specification.
Okay, I think I see what you're driving at. You are saying that
rational arithmetic is "right" (mathematically correct) and so
computations should be encouraged to happen rationally. A user who
*really* wants floating-point should have to be careful to say so.
I agree that we should be pushing rational arithmetic. But I think that
we should point out that use of a floating-point number anywhere in a
computation must be assumed to have "tainted" the result. I think it
would be misleading and less useful for (* pi 2) =>
884279719003555/140737488355328. It would certainly be confusing for
(* .001 10) => 42949675/4294967296. It's hard enough explaining that
(* .001 10) => 0.010000001.
I guess I prefer that any fuzziness in the computation be reflected in
fuzziness of the result. You could object that coercion should then
prefer the smaller precision rather than the larger, and I'd probably
agree.
From a pragmatic and language design point of view, I'd like to be able
to write generic functions which work on both rational and
floating-point numbers, such that rational inputs get rational results
and floating inputs get floating results of the same precision. I'd
prefer that the constants in those functions to be written rationally
when they're (mathematically) rational numbers. So I'd still like
coercion to prefer floating-point.
∂28-Jan-86 1823 hilfingr@renoir.berkeley.edu Re: IEEE float co-processors
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 28 Jan 86 18:23:15 PST
Received: by ucbvax.berkeley.edu (5.44/1.9)
id AA10532; Tue, 28 Jan 86 18:23:27 PST
Received: by renoir.berkeley.edu (5.44/5.16)
id AA07538; Tue, 28 Jan 86 18:23:15 PST
Resent-From: hilfingr@renoir.berkeley.edu (Paul Hilfinger)
Resent-Message-Id: <8601290223.AA07538@renoir.berkeley.edu>
Message-Id: <8601290223.AA07538@renoir.berkeley.edu>
Resent-To: common-lisp@su-ai.arpa
To: fateman@kim.berkeley.edu
Subject: Re: IEEE float co-processors
In-Reply-To: Your message of Tue, 28 Jan 1986 08:56 EST.
<FAHLMAN.12178838237.BABYL@C.CS.CMU.EDU>
Date: 28 Jan 86 12:24:12 PST (Tue)
From: hilfingr@renoir.berkeley.edu
Resent-Date: 28 Jan 86 16:10:21 PST (Tue)
> My only concern is that the interpreter would probably be stuck with
> doing the coercions at each step, and therefore might get a slightly
> different (less precise) answer than the compiler would come up with.
> Would that bother anyone? (Not me, but I only look at the first two
> digits anyway...)
I don't do numerical work, but working down the hall from a
particularly famous and outspoken numerical analyst as I do, I don't
dare be completely uninformed on the issue.
I think that one clearly wants the compiler and interpreter to give
identical results, not only for obvious reasons having to do with
debugging, but also for consistency with the CL campaign to bring
compiled and interpreted semantics closer together. Fateman's
proposal doesn't seem to make it hard for the interpreter to be
consistent with the compiler. For example, the implementation might
choose an implementation in which
1. All expressions of the form (arith-op a b c ...) are grouped
left-associatively (at least if one operand is floating point
and possibly always.
2. All arithmetic involving floating point is done in extended
precision, with the result being rounded to the appropriate
precision at the end.
Is there any difficulty in having either interpreter or compiler
follow this semantics?
Frankly, I think the freedom to re-arrange allowed on page 194 is a
bad idea for any expression that might involve floating point operands
(maybe for others, too, but my opinion isn't strong on that.) In
CL, of course, you don't have the freedom to say ``well, we'll compile
it this way for integers and ratios and that way for floating point''
because CL is not strongly typed. I therefore anticipate the
objection, ``well we don't want to lower the quality of code for the
usual case (some sort of integers, I presume).'' However, in the
absence of very clear, solid, empirical evidence suggesting
appreciable degradation of performance resulting from the compiler's
inability to reassociate expressions, I'd just as soon chuck the
flexibility.
There is a prevailing opinion that ``well, floating point is
approximate, so who cares? Why not rearrange as convenient?'' The
fact of the matter is that while floating point arithmetic is
approximate, it is ``approximate in a precise way'' (at least on most
architectures, and certainly on anything conforming to the IEEE
Standard 754.) For example, on most machines x+y, x*y, x-y, and x/y
all have the property that in the absence of over/underflow, the
result has a very small (order 2**(-number of binary digits of
precision or so)) RELATIVE error. Indeed, for addition (subtraction),
if the magnitudes of the operands are within a factor of 2 of each
other and the operands have opposite (the same) signs, so that
extensive cancellation occurs, the result is mathematically exact.
The common intuition that cancellation introduces error is completely
wrong. This property turns out to be very useful (for example, it
makes it possible to compute the area of a triangle with a simple
formula that works well even for very flat triangles.) It also
explains why some of us would like to avoid cavalier rounding of small
rationals to 0: doing so suddenly introduces a 100% relative error
into the computation. Better to get an error indication or the right
answer.
I suppose one could argue that usually, one doesn't care. For
integers and ratios this is certainly true, since the answer will be
identical in any case, unless something exceptional (and in particular
rare) happens. But when regrouping changes the answer in
unexceptional cases, and when important properties of that answer by
rights could be predicted by simple and well-understood rules if only
the grouping were predictable, one has to wonder.
Paul Hilfinger
∂28-Jan-86 2015 FAHLMAN@C.CS.CMU.EDU DEFUN inside LET
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Jan 86 20:11:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Jan 86 23:12:32-EST
Date: Tue, 28 Jan 1986 23:12 EST
Message-ID: <FAHLMAN.12178994051.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "James R. Meehan" <csi!meehan%UUCP@YALE.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: DEFUN inside LET
In-reply-to: Msg of 28 Jan 1986 10:06-EST from James R. Meehan <csi!meehan%UUCP at YALE.ARPA>
I'm not sure if there's actually a firm consensus on this, but in my
opinion Defun inside Let should always work. It's an idiom I use a lot,
and if some alleged Common Lisp didn't supply this, I'd either complain
or fix it myself.
-- Scott
∂29-Jan-86 1040 mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV Floating Point Computation
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 29 Jan 86 10:38:08 PST
Return-Path: <mcvax!nplmg1a.uucp!jrp>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Wed, 29 Jan 86 13:09:37 EST
From: mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV
Received: by mcvax.uucp; Wed, 29 Jan 86 18:43:01 +0100 (MET)
Received: by mcvax.uucp; Wed, 29 Jan 86 18:42:49 +0100 (MET)
Received: from nplmg1a.uucp by eagle.Ukc.AC.UK with UUCP id a000367;
29 Jan 86 16:44 GMT
To: common-lisp@su-ai.arpa
Subject: Floating Point Computation
Return-Receipt-To: mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV
Date: 29 Jan 86 16:38:25 GMT (Wed)
Message-Id: <1000.507400705@nplmg1a>
I hope that the following paper will put final rest to the speculations
on floating point arithmetic:-
Brown, W.S.,
A Simple but Realistic Model of Floating-Point Computation,
ACM Transactions on Mathematical Software Vol. 7 No. 4, Dec 81.
(Material is also to be found in the ADA reference manual)
Do not assume that the arithmetic on your machine is implemented
correctly (in hardware). Do not assume (particularly for UNIX-based
systems) that the text -> internal conversion routines are any good. Do
not assume that the elementary functions are any good on your machine.
You will not go far wrong!
John Pavel
∂29-Jan-86 1052 FAHLMAN@C.CS.CMU.EDU Floating Point Computation
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jan 86 10:52:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 29 Jan 86 13:52:43-EST
Date: Wed, 29 Jan 1986 13:52 EST
Message-ID: <FAHLMAN.12179154269.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: mcvax!nplmg1a.uucp!jrp@SEISMO.CSS.GOV
Cc: common-lisp@SU-AI.ARPA
Subject: Floating Point Computation
In-reply-to: Msg of 29 Jan 1986 11:38-EST from mcvax!nplmg1a.uucp!jrp at seismo.CSS.GOV
Thanks for the reference. I'm not sure what point you are trying to
make, however. Is there some specific recommendation lurking in here?
Or are you just saying that everything about floating-point is so
screwed up that we shouldn't waste time arguning about how to make it
better?
-- Scott
∂29-Jan-86 1133 fateman@dali.berkeley.edu Re: Floating Point Computation
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 29 Jan 86 11:32:59 PST
Received: by ucbvax.berkeley.edu (5.44/1.9)
id AA25344; Wed, 29 Jan 86 11:32:58 PST
Received: by dali.berkeley.edu (5.44/5.16)
id AA21319; Wed, 29 Jan 86 11:32:39 PST
Date: Wed, 29 Jan 86 11:32:39 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601291932.AA21319@dali.berkeley.edu>
To: common-lisp@su-ai.arpa, mcvax!nplmg1a.uucp!jrp@seismo.css.gov
Subject: Re: Floating Point Computation
Sorry to disappoint you, but
Brown's model was intended to provide a model to include nearly all
known horrors. It is hardly a prescription for what to do in
designing either a computer or a language.
∂29-Jan-86 1144 JAR@MC.LCS.MIT.EDU DEFUN inside LET
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 Jan 86 11:43:55 PST
Date: Wed, 29 Jan 86 14:45:27 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: DEFUN inside LET
To: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Tue 28 Jan 1986 23:12 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MC.LCS.MIT.EDU].800572.860129.JAR>
Date: Tue, 28 Jan 1986 23:12 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
I'm not sure if there's actually a firm consensus on this, but in my
opinion Defun inside Let should always work. It's an idiom I use a lot,
and if some alleged Common Lisp didn't supply this, I'd either complain
or fix it myself.
I don't understand how one can argue with p. 67 of CLtL which (to me)
unequivocally says that DEFUN inside LET should "work":
"Evaluating a DEFUN form causes the symbol ... to be a global name for
the function specified by the LAMBDA-expression ... in the lexical
environment in which the DEFUN form was executed."
Also, since DEFUN is a macro, it's hard to imagine what it could expand
into in order to behave much differently from this.
∂29-Jan-86 1206 FAHLMAN@C.CS.CMU.EDU DEFUN inside LET
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jan 86 12:05:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 29 Jan 86 15:06:10-EST
Date: Wed, 29 Jan 1986 15:06 EST
Message-ID: <FAHLMAN.12179167652.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: DEFUN inside LET
In-reply-to: Msg of 29 Jan 1986 14:45-EST from Jonathan A Rees <JAR at MC.LCS.MIT.EDU>
Fine, I'm happy to agree that this passage is unequivocal. One might
have been confused by the mumbling about "top-level forms" that
surrounds this passage, but let's not be. Does anyone out there want to
argue that DEFUN inside of LET is not required to work?
-- Scott
∂30-Jan-86 0702 NGALL@G.BBN.COM Re: DEFUN inside LET
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 06:58:56 PST
Date: 30 Jan 1986 09:58-EST
Sender: NGALL@G.BBN.COM
Subject: Re: DEFUN inside LET
From: NGALL@G.BBN.COM
To: JAR@MC.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]30-Jan-86 09:58:55.NGALL>
In-Reply-To: <[MC.LCS.MIT.EDU].800572.860129.JAR>
Date: Wed, 29 Jan 86 14:45:27 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: DEFUN inside LET
Date: Tue, 28 Jan 1986 23:12 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
I'm not sure if there's actually a firm consensus on this...
I don't understand how one can argue with p. 67 of CLtL which (to me)
unequivocally says that DEFUN inside LET should "work":
"Evaluating a DEFUN form causes the symbol ... to be a global name for
the function specified by the LAMBDA-expression ... in the lexical
environment in which the DEFUN form was executed."
That passage sounds unequivocal (by itself) to me too (and I am VERY
much in favor of DEFUNs in LETs). Unfortunately, on pg. 66, is this
very equivocal passage that may imply that a DEFUN inside a LET is not
guaranteed to work in CL:
"It is not illegal to use these forms at other than top level, but whether it
is meaningful to do so depends on context [talk about waffling!]. Compilers,
for example, may not recognize these forms properly in other than top-level
contexts."
As I recall, this is the passage that has prevented a "firm consensus" and
I think there was some sort of consensus that the passage should be clarified
to unequivocally allow DEFUNs in LETs (and to state more explicitly what
forms are not meaningful in which contexts).
Also, since DEFUN is a macro, it's hard to imagine what it could expand
into in order to behave much differently from this.
Imagine this:
(defmacro simple-defun (name lambda-list &body body)
`(setf (symbol-function ',name)
'(lambda ,lambda-list ,@body)))
The quote in front of the lambda ensures that the lambda expression is
defined in the null lexical environment.
-- Nick
∂30-Jan-86 0834 mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV Re: Floating Point Computation
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 30 Jan 86 08:31:41 PST
Return-Path: <mcvax!nplmg1a.uucp!jrp>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Thu, 30 Jan 86 11:10:05 EST
From: mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV
Received: by mcvax.uucp; Thu, 30 Jan 86 16:03:51 +0100 (MET)
Received: by mcvax.uucp; Thu, 30 Jan 86 16:03:33 +0100 (MET)
Received: from nplmg1a.uucp by eagle.Ukc.AC.UK with UUCP id a009312;
30 Jan 86 9:44 GMT
To: Fahlman@c.cs.cmu.edu
Cc: nplmg1a!jrp@seismo.CSS.GOV, common-lisp@su-ai.arpa
Subject: Re: Floating Point Computation
In-Reply-To: Your message of Wed, 29 Jan 1986 13:52 EST.
<FAHLMAN.12179154269.BABYL@C.CS.CMU.EDU>
Date: 30 Jan 86 09:42:27 GMT (Thu)
Message-Id: <1000.507462147@nplmg1a>
Thanks for the reference. I'm not sure what point you are trying to
make, however. Is there some specific recommendation lurking in here?
I don't think that I have anything very profound to say, save don't take
*anything* for granted when it comes to floating point. The reference
gives a number of simple axioms which *should* be satisfied by any
reasonable processor, but are surprisingly often not satisfied in all
cases. In any case, these axioms should permit you to determine what
you can resonably do with floating-point in what might be called a
"sane" environment.
By the way, there are a number of packages for assessing the
floating-point performance of a given processor (e.g. from NAG, the
Numerical Algorithms Group in Oxford).
And when it comes to "double-length" arithmetic...
Or are you just saying that everything about floating-point is so
screwed up that we shouldn't waste time arguning about how to make
it better?
I would not go that far, but when it comes to "double-length"
arithmetic...
John Pavel
∂30-Jan-86 1011 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: DEFUN inside LET
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 30 Jan 86 10:10:53 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000168; 30 Jan 86 13:33 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Wed, 29 Jan 86 17:47:51 GMT
Message-Id: <Wed Jan 29 17:47:51 1986 @ aiva.edinburgh.ac.uk>
To: Fahlman@c.cs.cmu.edu, meehan <@yale.arpa,@harvard.harvard.edu:meehan@csi>
Subject: Re: DEFUN inside LET
Cc: common-lisp@su-ai.arpa
Date: Tue, 28 Jan 1986 23:12 EST
From: "Scott E. Fahlman" <Fahlman@edu.cmu.cs.c>
I'm not sure if there's actually a firm consensus on this, but in my
opinion Defun inside Let should always work. It's an idiom I use a lot,
and if some alleged Common Lisp didn't supply this, I'd either complain
or fix it myself.
Another issue is what DEFUN inside LET should do. My understanding of Common
Lisp is that
(let ((a 1)) (defun f () a) ...)
is supposed to be equivalent (modulo implicit blocks, &c) to
(let ((a 1)) (setf (symbol-function 'f) #'(lambda () a)) ...)
but that in Scheme it is equivalent to
(let ((a 1)) (labels ((f () a)) ...))
In other words, does an internal DEFUN define a local or a global function?
My opinion now is that I would rather have it define a local function (a la
Scheme), because I think that looks better than a LABELS, because I use local
functions a lot, and because, to me, it seems more natural. But if I used
global functions defined inside environments a lot, I could well change my
mind since the SETF is clearly worse than LABELS (and hence more in need of a
sweetened syntax). At the moment, though, I'm not sure what a global DEFUN
inside a LET is supposed to express (i.e., what is it good for?).
-- Jeff
∂30-Jan-86 1130 FAHLMAN@C.CS.CMU.EDU Defun inside Let
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86 11:29:25 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jan 86 14:29:43-EST
Date: Thu, 30 Jan 1986 14:29 EST
Message-ID: <FAHLMAN.12179423154.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Defun inside Let
There can be no question at all on the point Jeff Dalton raises: when a
Defun occurs inside a Let or anywhere else, it changes the GLOBAL
function definition for the symbol in question. It is not a form of
LABELS.
-- Scott
∂30-Jan-86 1146 RAM@C.CS.CMU.EDU DEFUN inside of LET
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86 11:46:39 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 30 Jan 86 14:46:55-EST
Date: Thu, 30 Jan 1986 14:46 EST
Message-ID: <RAM.12179426294.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: DEFUN inside of LET
The meaning of DEFUN inside of LET has been discussed at least
twice before on thie mailing list. Each time some people say that
they aren't sure whether it is required to work, and the rest of the
people say that "The U.S. will look pretty wimpy in ISO standardization
if DEFUN doesn't work inside of LET."
If you have a lexical Lisp, DEFUN with a non-null environment will
work without any major effort. I can't think of any reason for
arbitrarily making the environment for DEFUN null, and I can think of
good reasons for not doing so. If you want a definition in a null
environment, you can always put the definition in a null environment.
It is my opinion that the notion of a top-level form doesn't make
sense in a lexical Lisp. This issue definitely needs to be clarified.
I think that passage in CLTL about top-level forms not being well
defined in non-top-level contexts should be flushed. It should be
replaced with text describing what the forms do. This opinion is
based on the assumption that it is reasonable to make definitions in a
non-null environment. Such definitions are clearly not in a top-level
context, so the semantics of definitions in non-top-level contexts
must be defined.
As to whether DEFUN makes a local definition, I would say no. It
seems to me that the semantics of defun is to change the global
function definition, no matter where it appears. Common Lisp has no
notion of a block which implicitly gloms onto definitions in its body.
If you want to make a local definition, you use a binding form.
Rob
P.S. Rambo for technical committee!
∂30-Jan-86 1304 DCP@SCRC-STONY-BROOK.ARPA Defun inside Let
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 13:03:18 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 405501; Thu 30-Jan-86 16:01:52-EST
Date: Thu, 30 Jan 86 16:08 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12179423154.BABYL@C.CS.CMU.EDU>
Message-ID: <860130160817.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Thu, 30 Jan 1986 14:29 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
There can be no question at all on the point Jeff Dalton raises: when a
Defun occurs inside a Let or anywhere else, it changes the GLOBAL
function definition for the symbol in question. It is not a form of
LABELS.
We've discussed this inside Symbolics, and we don't have a solution for
the following problem:
(let ((a 3)
(b 5))
(defun add-and-increment ()
(prog1 (+ a b)
(incf a)
(incf b)))
(defun sub-and-decrement ()
(prog1 (- a b)
(decf a)
(decf b))))
That's all fine and dandy. Now come the hard parts.
- What if I want to redefine add-and-increment to be
(defun add-and-increment (&optional amount)
(prog1 (+ a b)
(incf a amount)
(incf b amount)))
Is the system expected to know that >the old version< of
add-and-increment is a lexical closure over some variables and make the
new one share that same environment?
- What if I wanted to add a variable to the lexical environment? What
forms to I type to splice something in?
- What if I want to redefine add-and-increment to be interpreted? Are you
forcing all implementations to have the same compiler and interpreter
environment?
- Suppose you declare 'you are not allowed to redefine a function whose
old definition is closed over a non-null lexical environment and
expect it to inherit the old environment.' What if I interpret the
above LET. Am I allowed to compile just one of the functions? If
not, why not? If not, am I allowed to compile both? If so, how do I
manage that with the tools provided (which presumably compile on
thing at a time.) If I am allowed to compile just one, does that
enforce the same format for compiled and interpreted lexical
environments?
I don't have answers for any of those. It's not clear to me there ARE
answers to some of them. What if somebody on the ISO board thinks up
roughly the same questions? If somebody does have >answers<, I'd like
to hear them. My personal feeling is that DEFUN that requires a
non-null lexical environment, such as created by LET, is a timebomb
ticking quickly.
∂30-Jan-86 1405 JAR@MC.LCS.MIT.EDU Defun inside Let
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Jan 86 14:03:37 PST
Date: Thu, 30 Jan 86 17:05:05 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Sender: JAR0@MC.LCS.MIT.EDU
Subject: Defun inside Let
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 30 Jan 86 16:08 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].802081.860130.JAR0>
Date: Thu, 30 Jan 86 16:08 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
... That's all fine and dandy. Now come the hard parts.
Is the system expected to know that >the old version< of
add-and-increment is a lexical closure over some variables and make the
new one share that same environment?
- What if I wanted to add a variable to the lexical environment? What
forms to I type to splice something in?
...
I don't have answers for any of those. It's not clear to me there ARE
answers to some of them. What if somebody on the ISO board thinks up
roughly the same questions? If somebody does have >answers<, I'd like
to hear them. My personal feeling is that DEFUN that requires a
non-null lexical environment, such as created by LET, is a timebomb
ticking quickly.
The questions you raise are valid and important ones, but I don't see
what they have to do with DEFUN. They apply equally to SETQ, SETF,
FLET, LABELS, etc., and are bound to arise the minute you have lexical
closures at all. Yes, it would be nice to be able to update the code
for a closure, alter environments, and so forth, for debugging. But I
don't see why debugging questions should enter into this semantic
question. Is there some reason that DEFUN is different? If there's a
problem with making (DEFUN FOO ...) mean the same [except with respect
to debugging, which Common Lisp doesn't address anyhow] as (SETF
(SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...)), why isn't that problem also a
problem with the SETF form?
Jonathan
∂30-Jan-86 1426 smh@mit-ems.ARPA Re: DEFUN inside LET
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 14:25:34 PST
Received: by mit-ems.ARPA (4.12/4.8) id AA10164; Thu, 30 Jan 86 17:18:25 est
Date: Thu, 30 Jan 86 17:18:25 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8601302218.AA10164@mit-ems.ARPA>
To: DCP@SCRC-STONY-BROOK.ARPA, JAR%MC.LCS.MIT.EDU@mit-ems.ARPA,
NGALL%G.BBN.COM@mit-ems.ARPA
Subject: Re: DEFUN inside LET
Cc: common-lisp@SU-AI.ARPA
> From @SU-AI.ARPA:NGALL@G.BBN.COM Thu Jan 30 11:27:51 1986
>
> > Also, since DEFUN is a macro, it's hard to imagine what it could expand
> > into in order to behave much differently from this.
>
> Imagine this:
>
> (defmacro simple-defun (name lambda-list &body body)
> `(setf (symbol-function ',name)
> '(lambda ,lambda-list ,@body)))
>
> The quote in front of the lambda ensures that the lambda expression is
> defined in the null lexical environment.
Wouldn't one instead use:
(defmacro simple-defun (name lambda-list &body body)
`(setf (symbol-function ',name)
(function (lambda ,lambda-list ,@body))))
This would seem to capture the lexical environment quite unambiguously.
If, as DCP suggests, a defun that captures its lexical environment is
really a "time bomb", defun could be "fixed". But how could it be
possible to prohibit constructions like the above?
∂30-Jan-86 1506 DCP@SCRC-STONY-BROOK.ARPA Defun inside Let
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 15:05:47 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 405638; Thu 30-Jan-86 18:03:56-EST
Date: Thu, 30 Jan 86 18:10 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>,
Steven Haflich <smh@MIT-EMS.ARPA>
cc: DCP@SCRC-QUABBIN.ARPA, JAR%MC.LCS.MIT.EDU@MIT-EMS.ARPA,
NGALL%G.BBN.COM@MIT-EMS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].802081.860130.JAR0>,
<8601302218.AA10164@mit-ems.ARPA>
Message-ID: <860130181022.1.DCP@NEPONSET.SCRC.Symbolics.COM>
You two bring up the same point. What if DEFUN's macro expansion were
(setf (symbol-function 'foo) #'(lambda arglist . body))
Minor nit: some systems would lose the name of the function inside the
lambda. All compiled functions have names.
Disagreement with Rees: I think debugging questions should come into the
semantics of things. Some companies use debuggability and the power of
their debug tools as one of their selling points. Indeed this isn't
an issue for applications that don't alter functions, but it is
to developers. Anyway...
This is no different from defun. The problem is that there is a top
level functional form, #'(lambda ...) in this case, that the compiler
has to do something with. Maybe a compiler that sees such a thing in a
non-null lexical environment punts (this doesn't address several other
issues I raised). Then people will complain, and have to us, that it is
inefficient by generating interpreted code.
∂30-Jan-86 1529 REM@IMSSS Defun inside Let
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-30 15:28:45 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1986 January 30 15:26:53 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS> (this host known locally only)
To:DCP@SCRC-QUABBIN.ARPA
CC:Fahlman@C.CS.CMU.EDU,COMMON-LISP@SU-AI.ARPA
Subject: Defun inside Let
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA
S> Date: Thu, 30 Jan 1986 14:29 EST
S> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
S> when a Defun occurs inside a Let or anywhere else, it changes the
S> GLOBAL function definition for the symbol in question. It is not a
S> form of LABELS.
I agree, see my related opinion below.
D> Date: Thu, 30 Jan 86 16:08 EST
D> From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
D> (let ((a 3) (b 5))
D> (defun add-and-increment ()
D> (prog1 (+ a b) (incf a) (incf b)))
D> (defun sub-and-decrement ()
D> (prog1 (- a b) (decf a) (decf b))))
Clearly that creates two global function-bindings (definitions) to
function-objects each of which has access to the same lexical
environment (the one containing a and b initialized to 3 and 5 resp.).
I think we all agree so far.
D> That's all fine and dandy. Now come the hard parts.
D> - What if I want to redefine add-and-increment to be
D> (defun add-and-increment (&optional amount)
D> (prog1 (+ a b) (incf a amount) (incf b amount)))
If you just do a toplevel defun, you are replacing the old definition
with a new one that uses the null lexical environment instead of the
one with a and b used by the earlier definitions. Thus you are
probably making a mistake, doing something other than what you
obviously wanted to do. The old function-object still accesses the a,b
environment but is inaccessible, while the new function-object
currently function-bound to the symbol add-and-increment access the
null environment instead. But if you had explicitly recovered the
lexical environment from either add-and-increment or
sub-and-decrement (either will do in this case), and executed the new
DEFUN in that environment, then the new function-object could share
lexical a,b once again. In this particular example you can recover
from the mistake because even though the old add-and-increment
function-object is inaccessible so you can no longer recover the a,b
environment from it (unless your user interface has a history/undo
mechanism), you can still recover the environment from the
not-yet-lost sub-and-increment function-object which is still
function-bound to the sub-and-increment symbol thus accessible.
(However I don't know how to actually obtain explicit CLtL-level
access to that lexical environment; in earlier debate on macro
expansion didn't we decide that at present CLtL provides no such
mechanism for explicitly handling &environment stuff but ought to be
changed to provide it?)
D> Is the system expected to know that >the old version< of
D> add-and-increment is a lexical closure over some variables and make the
D> new one share that same environment?
I'd say definitely not. If you specify null lexical environment, by
doing a toplvel DEFUN, that's what you should get.
D> - What if I wanted to add a variable to the lexical environment? What
D> forms to I type to splice something in?
I'm under the impression lexical environments (except possibly the
null environment) can't get new variables once they are formed, but
there were suggestions to change this both for debugging reasons and
for consistency with the null environment.
D> - What if I want to redefine add-and-increment to be interpreted? Are you
D> forcing all implementations to have the same compiler and interpreter
D> environment?
Now the cans of worms really start to open. I'd say if there is a
mechanism for redefining functions inside a non-null lexical
environment, as in the a,b example above, or if by any other mechanism
it is possible to create a situation where some but not all functions
in a particular lexical environment are compiled, this implies that
both interpreted and compiled functions must access lexical
environments in the same way essentially, i.e. that there be just one
implementation of lexical environment that is used by both kinds of
code. (Well, it would maybe be possible to have two kinds of lexical
environments, one optimized for compiled code and one not, but allow
either kind of function to access either kind of environment, sort of
like the way interpreted functions can call compiled functions by
calling APPLY on the contents of the function cell and vice versa by
linking to COMPILED-CALLING-INTERPRETED or whatever which sets up a
call to APPLY. But then if you initially load some functions
interpreted and later compile them in memory you may be permanently
stuck with the compiled functions running slowly as they access the
non-compiled lexical environment.)
D> My personal feeling is that DEFUN that requires a
D> non-null lexical environment, such as created by LET, is a timebomb
D> ticking quickly.
Well, if the language allows the DEFUN to be done, but the implementor
doesn't take care to do things correctly, indeed poor programmers will
find their code blowing up whenever they trigger the bugs.
One major question for CL advocates. Has anybody written a completely
correct implemention of CL, with no exceptions whatsoever, with all
these esoteric/messy cases correctly handled, with both interpretor
and compiler doing the expected things, so that we can establish by
example that CLtL isn't self-contradictory?? I personally believe that
as currently documented CLtL is indeed self-contradictory, even after
all the typos have been fixed, and thus in some sense hopeless as a
standard, but I'd be glad if I was wrong.
∂30-Jan-86 1712 smh@mit-ems.ARPA Re: Defun inside Let
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 17:08:54 PST
Received: by mit-ems.ARPA (4.12/4.8) id AA10928; Thu, 30 Jan 86 20:03:44 est
Date: Thu, 30 Jan 86 20:03:44 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8601310103.AA10928@mit-ems.ARPA>
To: REM%IMSSS.MIT.EDU@mit-ems.ARPA
Subject: Re: Defun inside Let
Cc: common-lisp@su-ai.ARPA
> From @SU-AI.ARPA:REM@IMSSS Thu Jan 30 19:00:10 1986
>
> But if you had explicitly recovered the lexical environment from
> either add-and-increment or sub-and-decrement (either will do in this
> case), and executed the new DEFUN in that environment, then the new
> function-object could share lexical a,b once again.
> I'm under the impression lexical environments (except possibly the null
> environment) can't get new variables once they are formed, but there
> were suggestions to change this both for debugging reasons and for
> consistency with the null environment.
I'm under the same impression. There is a very good motivation for
hiding the insides of lexical closures: The compiler (and by
implication also the interpreter) is allowed to do whatever flow and
variable analysis it can in order to bum or completely eliminate
closures. By requiring that it be possible subsequently to modify a
closure, such analysis becomes impossible. See the four examples on
CLtL pp.88-9 where in one case the compiler can avoid making a closure,
and in another merge many closures into a single object.
These optimizations could be especially important when compiling
automatically-generated code. It is worth every bit of effort to make
CL compilers super-analyzing/optimizing, because that's the place in a
CL system that has the most leverage on language performance.
> Has anybody written a completely correct implemention of CL so that we
> can establish by example that CLtL isn't self-contradictory??
How would he know if he had? If knowing were so easy, compiler
validation wouldn't be the subject of so much research. And we
wouldn't hear about validation suites in Ada land that execute
such-and-so percentage of the language features...
∂30-Jan-86 1714 RAM@C.CS.CMU.EDU Defun inside Let
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86 17:13:57 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 30 Jan 86 20:13:52-EST
Date: Thu, 30 Jan 1986 20:13 EST
Message-ID: <RAM.12179485813.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA, "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Subject: Defun inside Let
In-reply-to: Msg of 30 Jan 1986 16:08-EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Date: Thursday, 30 January 1986 16:08-EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
To: Scott E. Fahlman <Fahlman>, common-lisp at SU-AI.ARPA
Re: Defun inside Let
That's all fine and dandy. Now come the hard parts.
- What if I want to redefine add-and-increment to be
...
Is the system expected to know that >the old version< of
add-and-increment is a lexical closure over some variables and make the
new one share that same environment?
No, and for the reson REM says. The new definition is in the
environment you define it in, which is null in this case. Common Lisp
doesn't need to be able to redefine functions within an old
environment. Perhaps a useful feature, but certainly not necessary to
make good use of definitions in non null-environments. This is more
of a programming environment issue than a lexical environment issue.
Uses of definitions in non-null environments are usually such that it
is easy to recompile the whole shebang. You can't do it with COMPILE,
but in Hemlock, all I have to do is "Compile Defun".
- What if I wanted to add a variable to the lexical environment? What
forms to I type to splice something in?
Not defined in Common Lisp. I have been living without it.
- What if I want to redefine add-and-increment to be interpreted? Are you
forcing all implementations to have the same compiler and interpreter
environment?
If you can't redefine it without its environment, you can't redefine
it to be interpreted without EVAL'ing it all, thus there is no problem.
- Suppose you declare 'you are not allowed to redefine a function whose
old definition is closed over a non-null lexical environment and
expect it to inherit the old environment.' What if I interpret the
above LET. Am I allowed to compile just one of the functions? If
not, why not? If not, am I allowed to compile both? If so, how do I
manage that with the tools provided (which presumably compile on
thing at a time.) If I am allowed to compile just one, does that
enforce the same format for compiled and interpreted lexical
environments?
Well, you can expect whatever you want... :-)
Spice Lisp doesn't let you use COMPILE on functions defined in a non-null
environment. Why not? Because it's hard to implement and not worth
the effort. Of course, Common Lisp COMPILE could just do nothing in
this case.
I don't have answers for any of those. My personal feeling is
that DEFUN that requires a non-null lexical environment, such as
created by LET, is a timebomb ticking quickly.
I think many of the cited problems are contingent in the assumption
that COMPILE lets you do everything you want to do. You are bothered
mostly by programming environment issues which Common Lisp mostly
doesn't address.
Rob
∂30-Jan-86 1723 mips!escargot.earl@glacier DEFUN inside of LET
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 17:23:29 PST
Received: by glacier with Sendmail; Thu, 30 Jan 86 17:21:39 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
id AA18926; Thu, 30 Jan 86 13:37:50 pst
Received: by escargot.UUCP (4.12/4.7)
id AA04616; Thu, 30 Jan 86 13:37:13 pst
Date: Thu, 30 Jan 86 13:37:13 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8601302137.AA04616@escargot.UUCP>
To: common-lisp@SU-AI.ARPA
In-Reply-To: Rob MacLachlan's message of Thu, 30 Jan 1986 14:46 EST
Subject: DEFUN inside of LET
No one has suggested that making DEFUN inside of LET not work is the
right thing (people have suggested that it may not be required by the
current wording of the Common Lisp manual). If someone feels that
DEFUN inside of LET shouldn't work, they ought to speak up!
∂30-Jan-86 1805 @SCRC-QUABBIN.ARPA,@EUPHRATES.SCRC.Symbolics.COM:Moon@SCRC-STONY-BROOK.ARPA Defun inside Let
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 18:02:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via INTERNET with SMTP id 240543; 30 Jan 86 20:59:51-EST
Date: Thu, 30 Jan 86 21:02 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Defun inside Let
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
cc: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].802081.860130.JAR0>
Message-ID: <860130210226.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 30 Jan 86 17:05:05 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Date: Thu, 30 Jan 86 16:08 EST
From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
The questions you raise are valid and important ones, but I don't see
what they have to do with DEFUN. They apply equally to SETQ, SETF,
FLET, LABELS, etc., and are bound to arise the minute you have lexical
closures at all. Yes, it would be nice to be able to update the code
for a closure, alter environments, and so forth, for debugging. But I
don't see why debugging questions should enter into this semantic
question. Is there some reason that DEFUN is different?
Yes, it defines a name in the global environment. This means the user
can talk about a particular DEFUN. A user can't talk about a particular
SETQ or a particular FLET in this way, because they don't have names.
I think calling this "debugging" is ducking a genuine issue of language
definition. "Making DEFUN inside of LET work" is not as simple as some
people seem to think, because the definition of what it means to "work"
is not simple and involves issues like the ones DCP raised, which have
been raised many times before and are probably the reason for the paragraph
on page 66 that everyone likes to dump on.
If there's a
problem with making (DEFUN FOO ...) mean the same [except with respect
to debugging, which Common Lisp doesn't address anyhow] as (SETF
(SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...)), why isn't that problem also a
problem with the SETF form?
Who says it isn't? The only difference is that users aren't accustomed to
writing (SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...)) all the time.
Let me put it this way. It's easy enough to say that (LET ... (DEFUN FOO ...))
has the same effect as (LET ... (SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...))),
and in fact I know of no implementation where that is not already true.
The problem comes when people try to use this to do real work. It
quickly becomes apparent that you have actually added a whole new
feature to the language, without much thought or standardization of how
it is to be used.
∂30-Jan-86 1805 DCP@SCRC-STONY-BROOK.ARPA Defun inside Let
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 17:59:15 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 405743; Thu 30-Jan-86 20:57:21-EST
Date: Thu, 30 Jan 86 21:03 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>,
Earl Killian <mips!escargot.earl@SU-GLACIER.ARPA>,
David C. Plummer <DCP@SCRC-QUABBIN.ARPA>, common-lisp@SU-AI.ARPA
cc: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
In-Reply-To: <RAM.12179485813.BABYL@C.CS.CMU.EDU>,
<8601302137.AA04616@escargot.UUCP>
Message-ID: <860130210351.3.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Thu, 30 Jan 1986 20:13 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I don't have answers for any of those. My personal feeling is
that DEFUN that requires a non-null lexical environment, such as
created by LET, is a timebomb ticking quickly.
I think many of the cited problems are contingent in the assumption
that COMPILE lets you do everything you want to do. You are bothered
mostly by programming environment issues which Common Lisp mostly
doesn't address.
That's right, I am bothered by programming environment. That isn't
necessarily an issue to the people who use the code, but it sure is an
issue to those that write it and have to debug it. [Actually, the users
never come into it; for all they know the program they are running is
written in Ada. This is only an issue for developers.] I agree it is
probably not in CL's domain to address these issues, but it shouldn't
prohibit it. Maybe another example?
(let ((counter 0))
(defun hairy-function-counter ()
counter)
(defun hairy-function (arg1 ...)
(incf counter)
...big-and-hairy-compuation-bound-to-get-
called-a-lot-and-have-bugs-that-need-fixing...))
Why, during my debugging cycle, should I be forced to have the counter
reset to 0 each time I need to change hairy-function?
Date: Thu, 30 Jan 86 13:37:13 pst
From: mips!escargot.earl@glacier (Earl Killian)
No one has suggested that making DEFUN inside of LET not work is the
right thing (people have suggested that it may not be required by the
current wording of the Common Lisp manual). If someone feels that
DEFUN inside of LET shouldn't work, they ought to speak up!
I have reservations.
∂30-Jan-86 1811 GJC@MC.LCS.MIT.EDU editing environments
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Jan 86 18:11:07 PST
Date: Thu, 30 Jan 86 21:12:29 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: editing environments
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU
In-reply-to: Msg of Thu 30 Jan 86 16:08 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].802352.860130.GJC>
I guess what you can say is that the 'text editor' (human readable)
will sectionalize the buffer in such a way so that a compile-region
is meaningfull only for the entire top-level-form, so that the question
of 'the environment editor' doesnt come up.
But lets face it, CL, as defined, is very compile-whole-file oriented.
It doesnt take into account very well the programming environment style
that has been in use with Emacs/LEDIT/MACLISP on the PDP-10 and the
Lispmachine for at least a decade. Constructs such as (in-package ...)
and (eval-when (compile) (setq *readtable* ...)) etc that cause the
most painful confusion to even our best attempts at making our program
editors deal with such thing are, in the final analysis, far too unconstrained
to be able to expect a uniform and well understood behavior.
It will be very difficult to come up with a workable model.
Greenblatt had some suggestions recently in private correspondence
that harken back to certain tricks that the famous MDL compiler "COMBAT"
used. Such analogies however do not add any comfort to the situation.
-gjc
∂30-Jan-86 1930 FAHLMAN@C.CS.CMU.EDU Defun inside Let
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86 19:23:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jan 86 22:23:40-EST
Date: Thu, 30 Jan 1986 22:23 EST
Message-ID: <FAHLMAN.12179509449.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Defun inside Let
I was about to reply to Plummer's objections, but discovered that others
had already said most of what I want to. I agree with Jonathan Rees and
with Rob Maclachlan on this issue.
It is certainly true that for debugging purposes, there are some useful
things that a Common Lisp environment might supply to make people with
debugging styles like Plummer's more comfortable. For example, it might
be nice to be able to grab a function's definition and say "I want to
define an additional function in the same lexical environment that
this guy sees" or "I want to redefine this function, but continue using
the lexical environment of the old definition (plus the following
additional lexical variables)". In most Common Lisp interpreters I have
seen (and all of the ones I've written), it's pretty trivial to add
that, though it does require descending to system-internal levels to do
it.
Nothing in Common Lisp makes this impossible or even very hard. We
could probably add a standard set of hooks to make such a feature
portable if we tried hard enough, but after all the hassle we went
through to put in the evalhook stuff, I'm not eager to go through that
sort of exercise again. Let the manufacturers compete to produce the
best debugging environment, each consistent with his machine's style and
philosophy of user interaction.
It is much harder to add such facilities for modifying compiled
functions that share a lexical environment. The easy way to do this
would be to follow the trail back to the source code, make the changes
the user wants, and then recompile the whole top-level form which
defines the lexical environment in question. I'm quite content to do
this by hand, but there's no reason that someone couldn't write a
package to do it automatically, much as flavor methods are now
recompiled when you change anything.
-- Scott
∂30-Jan-86 2050 meehan@YALE.ARPA
Received: from YALE.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 20:49:53 PST
Received: by Yale-Bulldog.YALE.ARPA; 30 Jan 86 23:47:30 EST (Thu)
Date: 30 Jan 86 23:47:30 EST (Thu)
From: James Meehan <meehan@YALE.ARPA>
Message-Id: <8601310447.AA06340@Yale-Bulldog.YALE.ARPA>
To: common-lisp@su-ai.arpa
[This may be a duplicate message. Our mail system is ill.]
I remember seeing some bboard mail on this topic, but I don't remember whether
there was a consensus: Is Common Lisp supposed to allow DEFUN inside
LET? I know I can say
(setf (symbol-function 'foo) #'(lambda ...))
and get much the same effect, but that's more awkward.
∂30-Jan-86 2055 FAHLMAN@C.CS.CMU.EDU
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86 20:55:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jan 86 23:55:50-EST
Date: Thu, 30 Jan 1986 23:55 EST
Message-ID: <FAHLMAN.12179526230.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: James Meehan <meehan@YALE.ARPA>
Cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 30 Jan 1986 23:47-EST from James Meehan <meehan at YALE.ARPA>
Your mail system must be ill. Your earlier message arrived and has
sparked a furious debate on the Common Lisp mailing list. I thought it
was a simple question, but apparently there's no such thing in this
forum.
-- Scott
∂31-Jan-86 0906 DLW@SCRC-STONY-BROOK.ARPA Defun inside Let
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 09:06:15 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 406162; Fri 31-Jan-86 12:04:41-EST
Date: Fri, 31 Jan 86 12:06 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12179423154.BABYL@C.CS.CMU.EDU>
Message-ID: <860131120618.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 30 Jan 1986 14:29 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
There can be no question at all on the point Jeff Dalton raises: when a
Defun occurs inside a Let or anywhere else, it changes the GLOBAL
function definition for the symbol in question. It is not a form of
LABELS.
Agreed. This is completely clear from the manual. If DEFUN inside LET
is valid Common Lisp (I think it is, modulo the general smokescreen of
the page 66 paragraph), then it changes the global definition.
∂31-Jan-86 0938 DLW@SCRC-QUABBIN.ARPA Defun inside Let
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 09:38:01 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 240693; Fri 31-Jan-86 12:35:03-EST
Date: Fri, 31 Jan 86 12:37 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860130210351.3.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <860131123758.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 30 Jan 86 21:03 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
That's right, I am bothered by programming environment.
I agree it is
probably not in CL's domain to address these issues, but it shouldn't
prohibit it. Maybe another example?
I believe that all the problems you've been talking about have to do
with the poor interaction between lexical scoping and incremental
programming. These poor interactions are discussed in the paper "The
Art of the Interpreter: Parts Zero, One, and Two" by Guy Steele and
Gerry Sussman. They are not incidental design flaws of Common Lisp;
they are part of the deep nature of lexical scoping. I don't think they
represent a "time bomb" in the language. They just show how lexical
scoping, itself, has problems when it comes to program development, when
used in this way. I don't think any language change is called for. If
anybody writes a textbook or something that makes recommendations about
programming practices and styles, though, they should take these
problems into account.
I hope Steele will correct me if I'm wrong.
∂31-Jan-86 1806 OLDMAN@USC-ISI.ARPA Defmacro inside of a let
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 12:33:37 PST
Date: 31 Jan 1986 15:33-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: Defmacro inside of a let
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:33:44.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.
We all agree that a defun should be ok inside a let. Why does
the language explicitly state that a defmacro evaluated inside a
let is ok but must IGNORE the lexical environment? (See the
first paragraph on page 145 of CLtL.)
-- Dan
∂31-Jan-86 1806 OLDMAN@USC-ISI.ARPA &environment
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 12:50:28 PST
Date: 31 Jan 1986 15:43-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: &environment
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:43:34.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.
Are there any restrictions on placement of the &environment
marker in a lambda list? Our implementation currently requires
that it be either after an &body or first if there is no &body.
-- Dan
∂31-Jan-86 1808 OLDMAN@USC-ISI.ARPA deftype with &key
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 12:58:27 PST
Date: 31 Jan 1986 15:58-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: deftype with &key
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:58:40.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.
In the area of minor cleanup, I propose that deftype add &key to
its list of legal lambda-list markers. I don't see why it is not
there now and it seems that it would be occationally useful.
-- Dan
∂31-Jan-86 2156 OLDMAN@USC-ISI.ARPA Defmacro inside of a let
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 12:33:37 PST
Date: 31 Jan 1986 15:33-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: Defmacro inside of a let
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:33:44.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.
We all agree that a defun should be ok inside a let. Why does
the language explicitly state that a defmacro evaluated inside a
let is ok but must IGNORE the lexical environment? (See the
first paragraph on page 145 of CLtL.)
-- Dan
∂31-Jan-86 2228 FAHLMAN@C.CS.CMU.EDU &environment
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 Jan 86 21:59:09 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 1 Feb 86 00:59:29-EST
Date: Sat, 1 Feb 1986 00:59 EST
Message-ID: <FAHLMAN.12179799956.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: OLDMAN@USC-ISI.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: &environment
In-reply-to: Msg of 31 Jan 1986 15:43-EST from OLDMAN at USC-ISI.ARPA
Lacking any evidence to the contrary, I would think that &environment
should be allowed to appear anywhere in the lambda list. Is it really
important to you that the location be restricted? I can't see why it
would be.
-- Scott
∂31-Jan-86 2306 OLDMAN@USC-ISI.ARPA &environment
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 12:50:28 PST
Date: 31 Jan 1986 15:43-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: &environment
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:43:34.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.
Are there any restrictions on placement of the &environment
marker in a lambda list? Our implementation currently requires
that it be either after an &body or first if there is no &body.
-- Dan
∂31-Jan-86 2337 OLDMAN@USC-ISI.ARPA get-setf-method-multiple-value
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 12:50:43 PST
Date: 31 Jan 1986 15:49-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: get-setf-method-multiple-value
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:49:30.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.
Could anyone give me some motivation for the existance of this
function? I don't understand what is ment by storing multiple
values into a generalized variable.
-- Dan
∂01-Feb-86 0025 OLDMAN@USC-ISI.ARPA deftype with &key
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 12:58:27 PST
Date: 31 Jan 1986 15:58-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: deftype with &key
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:58:40.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.
In the area of minor cleanup, I propose that deftype add &key to
its list of legal lambda-list markers. I don't see why it is not
there now and it seems that it would be occationally useful.
-- Dan
∂01-Feb-86 0051 Moon@SCRC-STONY-BROOK.ARPA Retraction
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 Jan 86 17:19:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 406640; Fri 31-Jan-86 20:17:17-EST
Date: Fri, 31 Jan 86 20:18 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Retraction
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860131201842.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comment: Remailed at SU-AI after delay caused by mailing list error.
Date: Thu, 30 Jan 86 21:02 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Defun inside Let
Let me put it this way. It's easy enough to say that (LET ... (DEFUN
FOO ...)) has the same effect as (LET ... (SETF (SYMBOL-FUNCTION 'FOO)
#'(LAMBDA ...))), and in fact I know of no implementation where that is
not already true.
As a couple of people have pointed out to me, they do not have the same
effect in Symbolics Release 6.1. I apologize for leaping without
looking. I assumed that because it worked in the newer software I was
running, I didn't need to check whether it worked in the released
version. I'll try to be more careful about opening my mouth in the future.
Anyway, the point I was trying to make was that we all agree that those two
forms are equivalent. The questions are (less important) does Common Lisp
say that these are legal forms, and (much more important) does Common Lisp
presently contain everything needed to effectively make use of that
programming technique.
∂01-Feb-86 0713 RAM@C.CS.CMU.EDU Defmacro inside of a let
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Feb 86 07:13:17 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sat 1 Feb 86 10:13:42-EST
Date: Sat, 1 Feb 1986 10:13 EST
Message-ID: <RAM.12179900850.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: OLDMAN@USC-ISI.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Defmacro inside of a let
That's because the compiler wants to be able to evaluate macros at
compile time. It would be impossible to compute the lexical
environment of a macro definition without actually interpreting the
surrounding code. This is basically impossible, and is almost
certainly not what you want. It is more obvious in the case of
MACROLET, which is usually embedded in random code somewhere. This is
explained to some degree on page 114.
If you really want a closure as macroexpansion function, you can
(setf (macro-function 'foo) #'(lambda (form env) ...))
In this case there is no problem, since the macro won't be defined
until the form is evaluated, in which case its environment will be
available.
Rob
∂01-Feb-86 0805 FAHLMAN@C.CS.CMU.EDU Retraction
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Feb 86 08:05:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 1 Feb 86 11:05:57-EST
Date: Sat, 1 Feb 1986 11:05 EST
Message-ID: <FAHLMAN.12179910348.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Retraction
In-reply-to: Msg of 31 Jan 1986 20:18-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Anyway, the point I was trying to make was that we all agree that those two
forms are equivalent. The questions are (less important) does Common Lisp
say that these are legal forms, and (much more important) does Common Lisp
presently contain everything needed to effectively make use of that
programming technique.
I believe that the consensus is that they are legal forms, the waffling
language about top-level forms notwithstanding. And I feel strongly
that the language has everything NEEDED to effectively make use of that
programming technique. We are missing a few things that would make it
more CONVENIENT, but those can easily be added on an
implementation-specific basis.
-- Scott
∂01-Feb-86 1235 Moon@SCRC-QUABBIN.ARPA get-setf-method-multiple-value
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 1 Feb 86 12:35:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 241003; Sat 1-Feb-86 15:32:32-EST
Date: Sat, 1 Feb 86 15:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: get-setf-method-multiple-value
To: OLDMAN@USC-ISI.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[USC-ISI.ARPA]31-Jan-86 15:49:30.OLDMAN>
Message-ID: <860201153520.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 31 Jan 1986 15:49-EST
From: OLDMAN@USC-ISI.ARPA
Could anyone give me some motivation for the existance of this
function? I don't understand what is ment by storing multiple
values into a generalized variable.
(setf (values a b c) (foo x y)) is a simple example. Presumably
this expands into (multiple-value-setq (a b c) (foo x y)). A
more interesting example would be
(setf (values (aref a i) (aref a j) (aref a k)) (foo x y))
This is a possible extension rather than standard Common Lisp because
some people thought it was too complicated and hard to understand,
although to me it seems like an obvious symmetry.
∂01-Feb-86 1500 Moon@SCRC-STONY-BROOK.ARPA deftype with &key
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Feb 86 15:00:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 407198; Sat 1-Feb-86 17:58:40-EST
Date: Sat, 1 Feb 86 18:00 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: deftype with &key
To: OLDMAN@USC-ISI.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[USC-ISI.ARPA]31-Jan-86 15:58:40.OLDMAN>
Message-ID: <860201180011.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 31 Jan 1986 15:58-EST
From: OLDMAN@USC-ISI.ARPA
In the area of minor cleanup, I propose that deftype add &key to
its list of legal lambda-list markers. I don't see why it is not
there now and it seems that it would be occationally useful.
I don't know why it's not there either. We put it into our DEFTYPE.
∂01-Feb-86 1630 GJC@MC.LCS.MIT.EDU Retraction
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Feb 86 16:25:55 PST
Date: Sat, 1 Feb 86 19:27:28 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject: Retraction
To: Moon@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Fri 31 Jan 86 20:18 EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].804711.860201.GJC>
If you spend too much effort being careful about what you say in terms
of the released software you might not have time to say anything
interesting. So dont be too careful. I would think that any
implementor would appreciate that position.
∂01-Feb-86 1638 smh@mit-ems.ARPA Re: Defun inside Let
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 1 Feb 86 16:38:39 PST
Received: by mit-ems.ARPA (4.12/4.8) id AA17208; Fri, 31 Jan 86 17:42:25 est
Date: Fri, 31 Jan 86 17:42:25 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8601312242.AA17208@mit-ems.ARPA>
To: DCP@SCRC-QUABBIN.ARPA
Subject: Re: Defun inside Let
Cc: common-lisp@su-ai.ARPA
> From DCP@SCRC-STONY-BROOK.ARPA Thu Jan 30 18:03:04 1986
> (setf (symbol-function 'foo) #'(lambda arglist . body))
> Minor nit: some systems would lose the name of the function inside the
> lambda. All compiled functions have names.
(↑ minor-nit 2): CLtL p.439 explicitly allows the first argument to
the compile function to be nil, allowing unnamed compiled functions.
Indeed, I can find nothing in the language spec suggesting that any
compiled or interpreted functional object necessarily has a name.
That Symbolics and others support such a slot, of course, is a big
debugging win.
∂02-Feb-86 1912 DCP@SCRC-STONY-BROOK.ARPA Nothing to do with Common Lisp
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Feb 86 19:12:17 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 407571; Sun 2-Feb-86 22:10:32-EST
Date: Sun, 2 Feb 86 22:17 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Nothing to do with Common Lisp
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860202221739.4.DCP@NEPONSET.SCRC.Symbolics.COM>
I'm getting tired of having some mailer kicking back this kind of crap
to me. First of all, the header that used to be my message has been
completely parsed out of existence. Second of all, I have no idea if I
can reply to MAILER-DAEMON or POSTMASTER and frankly I'm not about to
try. My only hope is that this is a 4.1 Unix system doing this, because
it was promised to me that 'the 4.2 mail system will fix everything.'
(I know that isn't true because our 4.2 still violates half of the
standard protocols.) Will somebody please either tell the losers to fix
their mailers or get them out of the distribution. Sorry to bother
everybody, but I don't know a better place for this gripe.
==============================
Received: from SCRC-STONY-BROOK.ARPA by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 241340; Sun 2-Feb-86 21:08:39-EST
Received: from SU-AI.ARPA by SCRC-STONY-BROOK.ARPA via INTERNET with SMTP id 407543; 2 Feb 86 21:09:51-EST
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 2 Feb 86 18:10:54 PST
Received: by CCA-UNIX.ARPA (4.12/4.7)
id AA12595; Fri, 31 Jan 86 22:24:08 est
Date: Fri, 31 Jan 86 22:24:08 est
From: ima!inmet!MAILER-DAEMON%cca-unix.arpa@cca-unix.arpa
Message-Id: <8602010324.AA12595@CCA-UNIX.ARPA>
Sender: inmet!MAILER-DAEMON%cca-unix.arpa@cca-unix.arpa
Subject: Returned mail: Unable to deliver mail
To: @SU-AI.ARPA.DCP@SCRC.ARPA
Received: by inmet.uucp (4.12/inmet)
id AA26477; Fri, 31 Jan 86 08:23:00 est
Date: Fri, 31 Jan 86 08:23:00 est
Message-Id: <8601311323.AA26477@inmet.uucp>
----- Transcript of session follows -----
554 ima!cca!@SU-AI.ARPA:DCP@SCRC... Unbalanced '>'
554 ima!cca!@SU-AI.ARPA:DCP@SCRC... Unbalanced '<'
554 ima!cca!@SU-AI.ARPA:DCP@SCRC... Unbalanced '>'
554 ima!cca!@SU-AI.ARPA:DCP@SCRC... Unbalanced '<'
554 ima!cca!@SU-AI.ARPA:DCP@SCRC... Unbalanced '>'
554 ima!cca!@SU-AI.ARPA:DCP@SCRC... Unbalanced '<'
554 norman... Unbalanced '>': Bad file number
554 norman... Unbalanced '>': Bad file number
554 norman... Unbalanced '<': Bad file number
554 norman... Unbalanced '<': Bad file number
554 norman... Unbalanced '>': Bad file number
554 norman... Unbalanced '>': Bad file number
554 norman... Unbalanced '<': Bad file number
554 norman... Unbalanced '<': Bad file number
554 norman... Unbalanced '>': Bad file number
554 norman... Unbalanced '>': Bad file number
554 norman... Unbalanced '<': Bad file number
554 norman... Unbalanced '<': Bad file number
----- Unsent message follows -----
Received: by inmet.uucp (4.12/inmet)
id AA26475; Fri, 31 Jan 86 08:23:00 est
Date: Fri, 31 Jan 86 08:23:00 est
Message-Id: <8601311323.AA26475@inmet.uucp>
From: David C. Plummer <cca!DCP@SCRC-QUABBIN.ARPA> <*SU-AI.ARPA:DCP*SCRC@cca.UUCP>
Subject: Defun inside Let
In-Reply-To: <RAM.12179485813.BABYL@C.CS.CMU.EDU>, <8601302137.AA04616@escargot.UUCP>
To: cca!Rob.cca!MacLachlan.cca!Earl.cca!Killian.cca!David.cca!C.cca!Plummer
To: c.cs.cmu.edu>!, <RAM <mips!escargot.earl@SU-GLACIER.ARPA>
To: scrc-quabbin.arpa>!, <DCP su-ai.arpa!common-lisp
Cc: cca!Scott cca!E. cca!Fahlman c.cs.cmu.edu>!, <Fahlman
Received: from SU-AI.ARPA (su-ai.arpa.ARPA) by CCA-UNIX.ARPA (4.12/4.7)
id AA20764; Thu, 30 Jan 86 21:45:07 est
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jan 86 17:59:15 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 405743; Thu 30-Jan-86 20:57:21-EST
Date: Thu, 30 Jan 86 21:03 EST
Message-Id: <860130210351.3.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Thu, 30 Jan 1986 20:13 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I don't have answers for any of those. My personal feeling is
that DEFUN that requires a non-null lexical environment, such as
created by LET, is a timebomb ticking quickly.
I think many of the cited problems are contingent in the assumption
that COMPILE lets you do everything you want to do. You are bothered
mostly by programming environment issues which Common Lisp mostly
doesn't address.
That's right, I am bothered by programming environment. That isn't
necessarily an issue to the people who use the code, but it sure is an
issue to those that write it and have to debug it. [Actually, the users
never come into it; for all they know the program they are running is
written in Ada. This is only an issue for developers.] I agree it is
probably not in CL's domain to address these issues, but it shouldn't
prohibit it. Maybe another example?
(let ((counter 0))
(defun hairy-function-counter ()
counter)
(defun hairy-function (arg1 ...)
(incf counter)
...big-and-hairy-compuation-bound-to-get-
called-a-lot-and-have-bugs-that-need-fixing...))
Why, during my debugging cycle, should I be forced to have the counter
reset to 0 each time I need to change hairy-function?
Date: Thu, 30 Jan 86 13:37:13 pst
From: mips!escargot.earl@glacier (Earl Killian)
No one has suggested that making DEFUN inside of LET not work is the
right thing (people have suggested that it may not be required by the
current wording of the Common Lisp manual). If someone feels that
DEFUN inside of LET shouldn't work, they ought to speak up!
I have reservations.
∂03-Feb-86 0639 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Re: Defun inside Let
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 3 Feb 86 06:38:33 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a002924; 2 Feb 86 18:54 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Sun, 2 Feb 86 18:34:00 GMT
Message-Id: <Sun Feb 2 18:34:00 1986 @ aiva.edinburgh.ac.uk>
To: common-lisp@su-ai.arpa
Subject: Re: Re: Defun inside Let
Date: Thu, 30 Jan 1986 14:29 EST
From: "Scott E. Fahlman" <Fahlman@edu.cmu.cs.c>
Subject: Defun inside Let
There can be no question at all on the point Jeff Dalton raises: when a
Defun occurs inside a Let or anywhere else, it changes the GLOBAL
function definition for the symbol in question. It is not a form of
LABELS.
To avoid any confusion: I agree with this interpretation of Common Lisp. What
I'm wondering (and I'm beginning to think I'll wish I'd never asked this) is
why this interpretation was chosen over that in Scheme. It's true that Common
Lisp doesn't normally go through forms and give certain subforms unusual
meanings, but is that all there is to it?
I have another question regarding functions, but this is only of the "Does
CLtL actually say everything it should?" variety. If I do
(flet ((b () 1)) (apply #'b ()))
I get 1, as expected, but if I use 'B or (SYMBOL-FUNCTION 'B) instead of #'b I
get an error telling me that B is undefined. It is clear that I should get
this error [see pp 90 (SYMBOL-FUNCTION) and 107 (APPLY applied to a symbol)].
The description of FUNCTION (p 87) also indicates that it should work in this
case ("fn is interpreted as if it had appeared..."). But then,
In particular, if fn is a symbol, the functional definition associated
with that symbol is returned; see SYMBOL-FUNCTION.
For quite a while, I didn't think carefully about this and assumed that
FUNCTION was equivalent to SYMBOL-FUNCTION when applied to symbols. And it
is equivalent except for symbols defined as local functions. Should the
description of FUNCTION explicitly mention this exception, or is it clear
enough as is?
I hope this does not contribute to another furious debate.
-- Jeff
∂03-Feb-86 0736 FAHLMAN@C.CS.CMU.EDU Defun inside Let
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Feb 86 07:35:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 3 Feb 86 10:37:14-EST
Date: Mon, 3 Feb 1986 10:37 EST
Message-ID: <FAHLMAN.12180429421.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK>
Cc: common-lisp@SU-AI.ARPA
Subject: Defun inside Let
In-reply-to: Msg of 2 Feb 1986 13:34-EST from Jeff Dalton <jeff%aiva.edinburgh.ac.uk at cs.ucl.ac.uk>
To avoid any confusion: I agree with this interpretation of Common Lisp. What
I'm wondering (and I'm beginning to think I'll wish I'd never asked this) is
why this interpretation was chosen over that in Scheme.
Basically, we felt that everyone viewed Defun as the way you change
global function definitions and that Labels was the way you set up
lexically scoped ones. You need both things, and they already had
perfectly good names. While we knew about Scheme and were happy to rip
off some of its good ideas, the roots of the language were in the
Maclisp tradition and that's the way we did things if there was no
good reason to change.
For quite a while, I didn't think carefully about this and assumed that
FUNCTION was equivalent to SYMBOL-FUNCTION when applied to symbols. And it
is equivalent except for symbols defined as local functions. Should the
description of FUNCTION explicitly mention this exception, or is it clear
enough as is?
It wouldn't hurt to spell this out a bit more clearly.
-- Scott
∂03-Feb-86 0952 gls@THINK-AQUINAS.ARPA Defun inside Let
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 3 Feb 86 09:52:35 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 3 Feb 86 12:52:52 est
Date: Mon, 3 Feb 86 12:54 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Defun inside Let
To: DLW@SCRC-QUABBIN.ARPA, DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860131123758.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <860203125415.1.GLS@THINK-JEHOSEPHAT.ARPA>
Date: Fri, 31 Jan 86 12:37 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Date: Thu, 30 Jan 86 21:03 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
That's right, I am bothered by programming environment.
I agree it is
probably not in CL's domain to address these issues, but it shouldn't
prohibit it. Maybe another example?
I believe that all the problems you've been talking about have to do
with the poor interaction between lexical scoping and incremental
programming. These poor interactions are discussed in the paper "The
Art of the Interpreter: Parts Zero, One, and Two" by Guy Steele and
Gerry Sussman. They are not incidental design flaws of Common Lisp;
they are part of the deep nature of lexical scoping. I don't think they
represent a "time bomb" in the language. They just show how lexical
scoping, itself, has problems when it comes to program development, when
used in this way. I don't think any language change is called for. If
anybody writes a textbook or something that makes recommendations about
programming practices and styles, though, they should take these
problems into account.
I hope Steele will correct me if I'm wrong.
Sure, I'll correct you if you're wrong. (I know you'll return the favor.)
--Guy
∂03-Feb-86 1059 REM%IMSSS.#Pup@SU-SCORE.ARPA Jeff Dalton's point
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Feb 86 10:58:59 PST
Received: from IMSSS by Score with Pup; Mon 3 Feb 86 10:39:00-PST
Date: 3 Feb 1986 1043-PST
From: Rem@IMSSS
Subject: Jeff Dalton's point
To: COMMON-LISP%SU-AI@SCORE
It seems (FUNCTION FOO) and (SYMBOL-FUNCTION 'FOO) are different;
former refers to whatever FOO would mean in that context as a function,
whereas latter refers explicitly to the global function cell of FOO.
In the section describing FUNCTION, instead of saying "see SYMBOL-FUNCTION"
it should say "cf SYMBOL-FUNCTION", so the casual reader will immediately
know a difference instead of an equivalence in function is being pointed out.
Anyone else agree?
(reply to whole list or REM%IMSSS@SCORE)
-------
∂03-Feb-86 1101 Moon@SCRC-STONY-BROOK.ARPA Re: Re: Defun inside Let
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Feb 86 11:00:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 408282; Mon 3-Feb-86 13:54:37-EST
Date: Mon, 3 Feb 86 13:55 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Re: Defun inside Let
To: common-lisp@SU-AI.ARPA
In-Reply-To: <Sun Feb 2 18:34:00 1986 @ aiva.edinburgh.ac.uk>
Message-ID: <860203135533.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 2 Feb 86 18:34:00 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
I have another question regarding functions, but this is only of the "Does
CLtL actually say everything it should?" variety. If I do
(flet ((b () 1)) (apply #'b ()))
I get 1, as expected, but if I use 'B or (SYMBOL-FUNCTION 'B) instead of #'b I
get an error telling me that B is undefined. It is clear that I should get
this error [see pp 90 (SYMBOL-FUNCTION) and 107 (APPLY applied to a symbol)].
The description of FUNCTION (p 87) also indicates that it should work in this
case ("fn is interpreted as if it had appeared..."). But then,
In particular, if fn is a symbol, the functional definition associated
with that symbol is returned; see SYMBOL-FUNCTION.
I believe this to be an editing error. This text is left over from an earlier
draft version of the manual, from before the day when full lexical scoping was adopted.
∂03-Feb-86 1646 vollum@SCRC-STONY-BROOK.ARPA Re: Defmacro inside of a let
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Feb 86 16:46:33 PST
Received: from SCRC-PEGASUS.ARPA by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 408712; Mon 3-Feb-86 18:15:05-EST
Received: by scrc-pegasus id AA02080; Mon, 3 Feb 86 18:11:08 est
Date: Mon, 3 Feb 86 18:11:08 est
From: Rob Vollum <vollum@scrc-pegasus>
To: OLDMAN@USC-ISI.ARPA, RAM@C.CS.CMU.EDU
Subject: Re: Defmacro inside of a let
Cc: common-lisp@SU-AI.ARPA
Date: Sat, 1 Feb 1986 10:13 EST
Message-Id: <RAM.12179900850.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: OLDMAN@USC-ISI.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Defmacro inside of a let
That's because the compiler wants to be able to evaluate macros at
compile time. It would be impossible to compute the lexical
environment of a macro definition without actually interpreting the
surrounding code. This is basically impossible, and is almost
certainly not what you want. It is more obvious in the case of
MACROLET, which is usually embedded in random code somewhere. This is
explained to some degree on page 114.
I may be missing something here, but it seems to me that the compiler
wants to process ALL toplevel forms at compile time. Of course the
compiler would have to interpret the surrounding code to calculate the
lexical environment. I don't see why this is basically impossible. This
is exactly what was being discussed in the recent "Defun inside LET"
controversy. As for not being what the programmer wanted, what about
the person that wants to (for whatever reason) write the following:
(let ((counter 0))
(defmacro conditional-expand (...args...)
(incf counter)
(if (< counter *some-level*)
`(an expansion)
`(another expansion))))
I'm not defending this code, or even saying that this is the only way
to do such a thing, but what's wrong with it linguistically?
[...]
Rob
Rob
∂03-Feb-86 1708 WEEKS@HP-THOR eval'd macros
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 3 Feb 86 17:08:28 PST
Received: from HP-THOR by hplabs.ARPA ; Mon, 3 Feb 86 16:36:02 pst
Date: Mon 3 Feb 86 16:24:29-PST
From: WEEKS%HP-THOR@HPLABS
Subject: eval'd macros
To: common-lisp@su-ai.ARPA
The following results occur on my workstation:
(defun fn () (mac)) ;==> FN
(defmacro mac () `'foo) ;==> MAC
(fn) ;==> ***Error***
It seems clear from CLtL, pg.143, second paragraph that (fn) should have
evaluated to FOO. [The reference to "local definitions" indicates that
the reference to "eval" really refers to evaluation in general.] Is the
above ***Error*** indeed wrong?
-------
∂03-Feb-86 1738 FAHLMAN@C.CS.CMU.EDU eval'd macros
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Feb 86 17:38:26 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 3 Feb 86 20:36:41-EST
Date: Mon, 3 Feb 1986 20:36 EST
Message-ID: <FAHLMAN.12180538540.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: WEEKS%HP-THOR@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: eval'd macros
(defun fn () (mac)) ;==> FN
(defmacro mac () `'foo) ;==> MAC
(fn) ;==> ***Error***
You don't say whether the problem you described occurs in the
interpreter or the compiler. Your example certainly is not required to
work when compiled because the macro definition follows the use. In my
opinion, this should work without an error in the interpreter. Hacking
in the interpreter would be fairly awkward if it didn't. However, the
fourth paragraph on page 143 seems to give implementors permission to do
compiler-like macro expansion when a defun is first seen. I wouldn't
want to use such an implementation, but it probably is legal as the
manual currently stands.
-- Scott
∂03-Feb-86 1905 RAM@C.CS.CMU.EDU Defmacro inside of a let
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Feb 86 19:05:09 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 3 Feb 86 22:07:00-EST
Date: Mon, 3 Feb 1986 22:06 EST
Message-ID: <RAM.12180554989.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Rob Vollum <vollum@SCRC-PEGASUS.ARPA>
Cc: common-lisp@SU-AI.ARPA, OLDMAN@USC-ISI.ARPA
Subject: Defmacro inside of a let
In-reply-to: Msg of 3 Feb 1986 18:11-EST from Rob Vollum <vollum at scrc-pegasus>
Date: Monday, 3 February 1986 18:11-EST
From: Rob Vollum <vollum at scrc-pegasus>
Re: Defmacro inside of a let
I may be missing something here, but it seems to me that the compiler
wants to process ALL toplevel forms at compile time. Of course the
compiler would have to interpret the surrounding code to calculate the
lexical environment. I don't see why this is basically impossible. This
is exactly what was being discussed in the recent "Defun inside LET"
controversy.
Well, the compiler does need to Process all top-level forms, but that
certainly doesn't normally entail EVAL'ing them. The compiler cannot
randomly eval any code just because it feels like it. Normally the
compiler only evals forms if an explicit EVAL-WHEN (COMPILE) is
present. Are you suggesting that the compiler should say "Oh, there's
a DEFMACRO buried in here somewhere, I'd better eval this thing." If
so, that seems linguistically quite unclean to me, since the presence
of a defmacro would have a nonlocal effect.
This isn't the same as DEFUN inside of LET, because DEFUN has no
effect at compile time. The actual evaluation of the defun is put off
until load time, when it is legal to evaluate the entire form.
Rob
∂04-Feb-86 0734 DCP@SCRC-STONY-BROOK.ARPA eval'd macros
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Feb 86 07:34:06 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 409168; Tue 4-Feb-86 10:27:29-EST
Date: Tue, 4 Feb 86 10:33 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: eval'd macros
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, WEEKS%HP-THOR@HPLABS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12180538540.BABYL@C.CS.CMU.EDU>
Message-ID: <860204103305.6.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 3 Feb 1986 20:36 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
(defun fn () (mac)) ;==> FN
(defmacro mac () `'foo) ;==> MAC
(fn) ;==> ***Error***
You don't say whether the problem you described occurs in the
interpreter or the compiler. Your example certainly is not required to
work when compiled because the macro definition follows the use. In my
opinion, this should work without an error in the interpreter. Hacking
in the interpreter would be fairly awkward if it didn't. However, the
fourth paragraph on page 143 seems to give implementors permission to do
compiler-like macro expansion when a defun is first seen. I wouldn't
want to use such an implementation, but it probably is legal as the
manual currently stands.
It should probably still work if compile-like macro expansion is done at
definition time. If the system goes further and actually DOES compile
the defun, then I would consider it a user-interface bug that the
compiler doesn't tell the user that it couldn't find a function call
MAC.
(defun fn () (mac))
FN
(compile 'fn)
The following functions were referenced but don't seem defined:
MAC referenced by FN
FN
∂04-Feb-86 0739 gallagher%umass-cs.csnet@CSNET-RELAY.ARPA Defstruct Extensions
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Feb 86 07:39:46 PST
Received: from umass-cs by csnet-relay.csnet id aw12431; 4 Feb 86 1:18 EST
Date: Mon, 3 Feb 86 13:15 EST
From: Kevin Gallagher <gallagher%umass-cs.csnet@CSNET-RELAY.ARPA>
To: Common-Lisp@su-ai.ARPA
Subject: Defstruct Extensions
I think it is a deficiency in the language that you can't access a slot in a
structure via the slot name. Every implementation keeps this information
around and anyone who is writing a layered system eventually needs that
ability and writes a non-portable slot getter. Structure definition
information should be available also.
I propose the addition of several functions to the language:
GET-STRUCTURE-SLOT structure slot [Function]
Returns the value of the slot in STRUCTURE specified by SLOT. SETF may be
used with GET-STRUCTURE-SLOT to modify a slot in a structure.
STRUCTURE-SLOT-NAMES name [Function]
NAME must be a type defined by DEFSTRUCT. This function returns a list of
slot names for structures of that type.
Also nice but not quite so important would be:
MAKE-STRUCTURE name slot-keyword-1 form1 ... [Function]
Creates an instance of a structure. NAME is the type of structure to
create. The rest of the arguments are the same as for the default
constructor function. If a slot is not initialised by a slot-keyword,
then the slot will be initialized with the default init form specified in
the defstruct.
STRUCTURE-OPTION name option [Function]
NAME must be a type defined by defstruct. OPTION must be a defstruct
option (e.g., :conc-name). This function returns the argument that was
given to that option if an argument was given in the call to defstruct.
Otherwise it returns the default value of that option.
For example, after the defstruct on page 312,
(structure-option 'astronaut :conc-name) ==> astro-
STRUCTURE-SLOT-OPTION name slot option [Function]
(This function is included mostly for completeness.)
NAME must be a type defined by defstruct. SLOT is the name of a slot in
that defstruct. OPTION must be a defstruct slot option (:type or
:read-only). This function returns the argument that was given to that
option if an argument was given in the call to defstruct. Otherwise it
returns the default value of that option.
Kevin Gallagher
∂04-Feb-86 0916 liz@brillig.umd.edu loop macro
Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 4 Feb 86 09:15:52 PST
Received: by brillig.umd.edu (5.9/4.7)
id AA04805; Tue, 4 Feb 86 12:16:40 EST
Message-Id: <8602041716.AA04805@brillig.umd.edu>
To: common-lisp@su-ai.ARPA, gls@think-aquinas.ARPA, vrotney@isi-vax.ARPA
Cc: Bruce Israel <israel@brillig.umd.edu>
Subject: loop macro
In-Reply-To: Your message of Thu, 23 Jan 86 17:45:08 EST.
<8601232245.AA22847@brillig.umd.edu>
Date: 04 Feb 86 12:16:39 EST (Tue)
From: Liz Allen <liz@brillig.umd.edu>
This is in response to a request for a loop macro that will run in
Common Lisp.
At Maryland, we've been using a for macro that provides a nice
looping macro and depends on almost nothing -- cond, setq, progn
and do is about all. It is a version of the InterLisp for macro
with a number of new keywords. If anyone would like the code for
it, let me know. There are a some examples of using it and
descriptions of some of the other keywords below so you can get
some feeling for it. It expands into a call to do with, possibly,
a let around it so it runs fairly efficiently.
(for x in '(a b c) do (print x))
(for x in '(a b c)
y in '(d e f)
collect (cons x y))
==> ((a . d) (b . e) (c . f))
(for x in '(a b c) join (list x 3))
==> (a 3 b 3 c 3)
(for x in '(a b 3 4 c 5)
when (numberp x)
sum (print x) ; all clauses may contain multiple expressions
x)
prints: 3 4 5
==> 12
(for n from 0 to 13
when (> n 6)
quit n)
==> 7
To bind variables, you can use: "on" (same syntax as "in"),
destructuring with "in" (eg "(for (key . value) in assoc-list ...)"),
"let" to bind variables you want to see in later binding clauses, and
"bind" and "being" for other iteration variables.
Various conditions you can use are: "when", "unless", "while" and
"until". The body keywords are: "do", "collect", "join", "sum",
"count", "alwyas", "never", "thereis", "last", "tcollect", "tjoin"
(like collect and join except using tconc cells) and "quit" (like
return). There are also "initially" and "finally" clauses.
All the clauses that expect lisp bodies may have multiple clauses and
an implicit progn is put around them.
The value of the for is kept in the local variable $$val -- that's
especially useful in the "finally" clause.
Enjoy!
-Liz
∂04-Feb-86 0952 kempf@hplabsc Re: Defstruct Extensions
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 4 Feb 86 09:50:21 PST
Received: from hplabsc by hplabs.ARPA ; Tue, 4 Feb 86 09:49:10 pst
Received: by hplabsc (4.16/4.30) ;
id AA05360; Tue, 4 Feb 86 09:52:19 pst
Date: Tue, 4 Feb 86 09:52:19 pst
From: Jim Kempf <kempf@hplabsc>
Message-Id: <8602041752.AA05360@hplabsc>
To: Common-Lisp@su-ai.ARPA, gallagher%umass-cs.csnet@CSNET-RELAY.ARPA
Subject: Re: Defstruct Extensions
>I think it is a deficiency in the language that you can't access a slot in a
>structure via the slot name. Every implementation keeps this information
>around and anyone who is writing a layered system eventually needs that
>ability and writes a non-portable slot getter. Structure definition
>information should be available also.
I would agree with this, except I would go one step further.
Currently, the default underlying data structure for defstruct's is
unspecified. An implementation can choose to use vectors, lists
or any other of the existing data structures. An enhancement to
portablility would be to specify the underlying data structure,
and provide portable accessor functions for getting it. An
obvious choice is a vector-like data structure, which is, nevertheless,
distinct from a vector. This would also be useful to implementors
of object-oriented CL extensions.
>
> GET-STRUCTURE-SLOT structure slot [Function]
>
> Returns the value of the slot in STRUCTURE specified by SLOT. SETF may be
> used with GET-STRUCTURE-SLOT to modify a slot in a structure.
>
Jim Kempf kempf@hplabs
If the default data structure is a vector, then this function should
also take an integer index. Compilers would be able to utilize this
information to optimize structure access for variables declared
as structures.
∂04-Feb-86 1005 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: eval'd macros
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 4 Feb 86 10:04:13 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a001025; 4 Feb 86 17:14 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Tue, 4 Feb 86 17:21:42 GMT
Message-Id: <Tue Feb 4 17:21:42 1986 @ aiva.edinburgh.ac.uk>
To: WEEKS <@hplabs.arpa:WEEKS@hp-thor>, common-lisp@su-ai.arpa
Subject: Re: eval'd macros
Date: Mon 3 Feb 86 16:24:29-PST
From: WEEKS <WEEKS%hp-thor@arpa.hplabs>
Subject: eval'd macros
The following results occur on my workstation:
(defun fn () (mac)) ;==> FN
(defmacro mac () `'foo) ;==> MAC
(fn) ;==> ***Error***
It seems clear from CLtL, pg.143, second paragraph that (fn) should have
evaluated to FOO. [The reference to "local definitions" indicates that
the reference to "eval" really refers to evaluation in general.] Is the
above ***Error*** indeed wrong?
Sounds like your workstation is wrong. I've also tried it in 3 different
implementations of Common Lisp, and they all say FOO.
∂04-Feb-86 1029 KMP@SCRC-STONY-BROOK.ARPA eval'd macros (the other point of view)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Feb 86 10:25:02 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 409419; Tue 4-Feb-86 13:24:52-EST
Date: Tue, 4 Feb 86 13:24 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: eval'd macros (the other point of view)
To: Fahlman@C.CS.CMU.EDU, WEEKS%HP-THOR@HPLABS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12180538540.BABYL@C.CS.CMU.EDU>
Message-ID: <860204132441.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 3 Feb 1986 20:36 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
(defun fn () (mac)) ;==> FN
(defmacro mac () `'foo) ;==> MAC
(fn) ;==> ***Error***
I wish we'd required that this signal an error. I like the behavior shown above.
You don't say whether the problem you described occurs in the
interpreter or the compiler. Your example certainly is not required to
work when compiled because the macro definition follows the use. In my
opinion, this should work without an error in the interpreter. Hacking
in the interpreter would be fairly awkward if it didn't. However, the
fourth paragraph on page 143 seems to give implementors permission to do
compiler-like macro expansion when a defun is first seen. I wouldn't
want to use such an implementation, but it probably is legal as the
manual currently stands.
Well, people frequently don't like to use something that behaves differently
than what they're used to, but that doesn't make the `new' behavior wrong.
In the interest of fairness, let me outline the alternate point of view -- the
view to which I subscribe...
Having macros expanded when the defun is first seen offers the nice feature
that you can't easily break functions you've already written as you enter a
debugging phase. For example, consider how redefining LET would break the world
in an environment where LET wasn't resolved at definition time. Compare that
to a world where you had to do things in order. You're always trading one thing
for another.
Also, in your preferred interpreter, allowing displacing macros to expand
lazily will mean that code which is fully loaded but only partially exercised
may behave inconsistently after redefinition of a macro, since only the
non-displaced calls will see the update. In the case of an early-binding
interpreter, the effect of the redefinition is trivially predictable.
Personally, I would prefer not to work in an interpreter that did lazy
expansion. The only weakness I see in the spec is that it doesn't guarantee
early expansion.
∂04-Feb-86 1032 Gregor.pa@Xerox.COM Re: Defstruct Extensions
Received: from XEROX.COM by SU-AI.ARPA with TCP; 4 Feb 86 10:28:54 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 FEB 86 09:54:35 PST
Date: 4 Feb 86 09:54 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Defstruct Extensions
In-reply-to: Kevin Gallagher <gallagher@umass-cs.CSNET>'s message of
Mon, 3 Feb 86 13:15 EST
To: gallagher%umass-cs.CSNet@CSNet-Relay.ARPA
cc: Common-Lisp@su-ai.ARPA
Message-ID: <860204-095435-1945@Xerox>
Several of these functions exist in CommonLoops. In addition, the
metaclass mechanism makes it easy to make Portable CommonLoops (PCL)
deal with a particular CommonLisp's defstruct types as "first class"
classes.
This means that if you have a version of PCL which has been "taught"
about the particular Common Lisp's local type system you can use the PCL
functions to get the information you need regardless of whether you are
asking about a type defined by defstruct or a CommonLoops class.
In CommonLoops:
GET-STRUCTURE-SLOT is called GET-SLOT
STRUCTURE-SLOT-NAMES is called ALL-SLOTS
MAKE-STRUCTURE is called MAKE
STRUCTURE-OPTION
STRUCTURE-SLOT-OPTION
don't exist as named functions, but it might be a good idea to add them.
Of course, the only interesting part is making them setfable.
∂04-Feb-86 1037 FAHLMAN@C.CS.CMU.EDU eval'd macros (the other point of view)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Feb 86 10:36:38 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 4 Feb 86 13:36:59-EST
Date: Tue, 4 Feb 1986 13:36 EST
Message-ID: <FAHLMAN.12180724282.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: eval'd macros (the other point of view)
In-reply-to: Msg of 4 Feb 1986 13:24-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Having macros expanded when the defun is first seen offers the nice feature
that you can't easily break functions you've already written as you enter a
debugging phase.
You also can't FIX functions you've already written by changing the
macros they call. You now have to go back and find every last function
that calls FOO, and re-expand it to do the right thing, assuming that
you've got the source handy. Things that I'm sure are right and that I
don't want to break are usually already compiled.
-- Scott
∂04-Feb-86 1103 FAHLMAN@C.CS.CMU.EDU loop macro
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Feb 86 11:03:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 4 Feb 86 14:04:27-EST
Date: Tue, 4 Feb 1986 14:04 EST
Message-ID: <FAHLMAN.12180729252.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Liz Allen <liz@BRILLIG.UMD.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: loop macro
In-reply-to: Msg of 4 Feb 1986 12:16-EST from Liz Allen <liz at brillig.umd.edu>
Liz,
Your For macro sounds interesting in its own right, but I get the
impression that it is enough different from the Lisp Machine version
that it would not be of much help in porting Loop-infested Lisp Machine
code into Common Lisp. Is that right? Do you have any experience with
such ports?
-- Scott
∂04-Feb-86 1119 FAHLMAN@C.CS.CMU.EDU loop macro
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Feb 86 11:03:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 4 Feb 86 14:04:27-EST
Date: Tue, 4 Feb 1986 14:04 EST
Message-ID: <FAHLMAN.12180729252.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Liz Allen <liz@BRILLIG.UMD.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: loop macro
In-reply-to: Msg of 4 Feb 1986 12:16-EST from Liz Allen <liz at brillig.umd.edu>
Liz,
Your For macro sounds interesting in its own right, but I get the
impression that it is enough different from the Lisp Machine version
that it would not be of much help in porting Loop-infested Lisp Machine
code into Common Lisp. Is that right? Do you have any experience with
such ports?
-- Scott
∂04-Feb-86 1319 liz@brillig.umd.edu Re: loop macro
Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 4 Feb 86 13:18:49 PST
Received: by brillig.umd.edu (5.9/4.7)
id AA07277; Tue, 4 Feb 86 16:19:17 EST
Message-Id: <8602042119.AA07277@brillig.umd.edu>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Re: loop macro
In-Reply-To: Your message of Tue, 4 Feb 1986 14:04 EST.
<FAHLMAN.12180729252.BABYL@C.CS.CMU.EDU>
Date: 04 Feb 86 16:19:16 EST (Tue)
From: Liz Allen <liz@brillig.umd.edu>
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Your For macro sounds interesting in its own right, but I
get the impression that it is enough different from the
Lisp Machine version that it would not be of much help in
porting Loop-infested Lisp Machine code into Common Lisp.
Is that right? Do you have any experience with such ports?
Well, I've only just started using the Lisp Machine Loop macro
recently and its syntax isn't quite what I tend to expect, so I'm
not sure how much I can say. There was someone who ported YAPS to
a Lisp Machine a while back who said that it was easy to translate
all the for's into loop's so it might not be *too* bad to go the
other way. Probably the biggest thing missing from our for macro
is the ability to accumulate multiple values in a single for (but
then, Franz Lisp 38.91 didn't have the concept of returning multiple
values from a function...). It would probably not be too hard to
add that feature -- the $$val stuff would have to be revised, but
in principle, there is no reason we couldn't extend it (except I'm
trying to work on a PhD thesis!).
-Liz
∂04-Feb-86 1332 BSG@SCRC-STONY-BROOK.ARPA Re: loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Feb 86 13:32:01 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 409709; Tue 4-Feb-86 16:30:31-EST
Date: Tue, 4 Feb 86 16:38 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: loop macro
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8602042119.AA07277@brillig.umd.edu>
Message-ID: <860204163848.9.BSG@CONCORD.SCRC.Symbolics.COM>
Date: 04 Feb 86 16:19:16 EST (Tue)
From: Liz Allen <liz@brillig.umd.edu>
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Your For macro sounds interesting in its own right, but I
get the impression that it is enough different from the
Lisp Machine version that it would not be of much help in
porting Loop-infested Lisp Machine code into Common Lisp.
Is that right? Do you have any experience with such ports?
Well, I've only just started using the Lisp Machine Loop macro
recently and its syntax isn't quite what I tend to expect, so I'm
not sure how much I can say. There was someone who ported YAPS to
a Lisp Machine a while back who said that it was easy to translate
all the for's into loop's so it might not be *too* bad to go the
other way. Probably the biggest thing missing from our for macro
is the ability to accumulate multiple values in a single for (but
then, Franz Lisp 38.91 didn't have the concept of returning multiple
values from a function...). It would probably not be too hard to
add that feature -- the $$val stuff would have to be revised, but
in principle, there is no reason we couldn't extend it (except I'm
trying to work on a PhD thesis!).
-Liz
I don't understand the general topic of discussion here. This Maryland
FOR macro hasn't a dime's worth of difference from Zetalisp LOOP. The
differences are trifling. I thought the issue with LOOP vs. CL was not
one of trivial differences between a large number of Interlisp-like loop
macros, but rather one of whether we wanted such a thing, extremely
non-lispy, however useful, to some tastes, in the language.
∂04-Feb-86 1416 FAHLMAN@C.CS.CMU.EDU loop macro
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Feb 86 14:15:47 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 4 Feb 86 17:10:17-EST
Date: Tue, 4 Feb 1986 17:10 EST
Message-ID: <FAHLMAN.12180763116.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: loop macro
In-reply-to: Msg of 4 Feb 1986 16:38-EST from Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>
I don't understand the general topic of discussion here. This Maryland
FOR macro hasn't a dime's worth of difference from Zetalisp LOOP. The
differences are trifling. I thought the issue with LOOP vs. CL was not
one of trivial differences between a large number of Interlisp-like loop
macros, but rather one of whether we wanted such a thing, extremely
non-lispy, however useful, to some tastes, in the language.
There are a couple of issues here. One is whether we want something
like the Loop macro added to the Common Lisp standard; the other is
whether anyone has a portable LOOP package that can be used as an
add-on. On the former issue, there seem to be three schools of thought:
1. We don't need such a thing. DO and related constructs do the job
just fine without adding a lot of extra hair.
2. The Lisp Machine's LOOP facility is essential for high-efficiency
programming and should be added to Common Lisp. (Discussions of
actually doing this usually get derailed by someone saying "..but there
are some problems with the current LOOP system, so everyone should wait
until we've figured out what the ultimate best thing is.")
3. The functionality of LOOP is fine, modulo some small details, but the
cute English-like syntax should be replaced with something more Lispy.
Specifically, parentheses should be used to group the arguments
controlling the various major options rather than doing this with
connecting words like "by", "until", and "whereas". People in this
group feel pretty strongly that the little pseudo-sentences people end
up writing in the LOOP syntax are extremely confusing and promote bad
style. Things that aren't English shouldn't look like English.
I used to be in group 1, but have now moved to group 3. I don't think
there are very many people left who actually favor option 1. A year or
so ago I proposed that we try to compromise with a scheme that basically
implements proposal 3, but with English-like LOOP syntax available as an
alternative syntax (a simple one-to-one mapping) for people who like
that kind of stuff. This suggestion went nowhere, and I haven't seen
any activity on the iteration mailing list since then. Deadlock, and
position 1 wins by default.
So much for standardizing on one of these things. The more recent
discussion was, I think, sparked by somebody's desire to move some
Loop-infested code from Zetalisp to a vanilla Common Lisp. While I
don't want to see us standardize on the Loop syntax, I must admit that
having a portable, compatible Loop package would make a lot of people's
lives easier as they move code from one system to another. So the
question of how close the Maryland code was to the current Zetalisp
stuff was of some immediate practical interest.
-- Scott
∂04-Feb-86 1434 sean@cadre.dsl.pittsburgh.edu Re: loop macro
Received: from CADRE.DSL.PITTSBURGH.EDU by SU-AI.ARPA with TCP; 4 Feb 86 14:33:28 PST
Received: by PITTSBURGH.EDU (5.31/5.14)
id AA27950; Tue, 4 Feb 86 17:33:15 EST
Date: Tue, 4 Feb 86 17:33:15 EST
From: sean@cadre.dsl.pittsburgh.edu (Sean McLinden)
Message-Id: <8602042233.AA27950@PITTSBURGH.EDU>
To: Fahlman@c.cs.cmu.edu, liz@brillig.umd.edu
Subject: Re: loop macro
Cc: common-lisp@su-ai.arpa
There was a version of the ZetaLisp LOOP macro which was ported
to Perq (Spice) Common Lisp by David Miller at DePaul University.
It supported everything in ZetaLisp except the NAMED keyword and
user defined iteration paths. We have modified that version to
accept either the Zetalisp or the Common Lisp LOOP syntax and
have had no problem in dealing with Zetalisp code.
I would be glad to distribute it to interested sites, assuming that
it was obtained from the Zetalisp sources without restriction
(I am not aware of any), and David Miller has no objection.
Sean McLinden
Decision Systems Laboratory
University of Pittsburgh
∂04-Feb-86 1552 Gregor.pa@Xerox.COM Re: loop macro
Received: from XEROX.COM by SU-AI.ARPA with TCP; 4 Feb 86 15:51:59 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 FEB 86 15:51:11 PST
Date: 4 Feb 86 15:50 PST
From: Gregor.pa@Xerox.COM
Subject: Re: loop macro
In-reply-to: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>'s message
of Tue, 4 Feb 86 16:38 EST
To: BSG@SCRC-STONY-BROOK.ARPA
cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Message-ID: <860204-155111-2418@Xerox>
I think I prefer "lispy" iteration macros. Here is an example of what I
mean by a lispy iteration macro:
;; Return a list of the items in list-of-items
;; which pass the test TEST.
(iterate ((item in list-of-items))
(when (test item)
(collect item)))
I like this better because:
-the bindings looks more like standard lisp bindings (let do etc).
-I can use COLLECT, SUM etc. at any level in the body.
-uses of collect sum etc. look like lisp function calls.
-which makes it natural to use the existing when, unless etc.
NOTE: I am not proposing this version of ITERATE as something we
should consider in and of itself, I am just using it to show
some things I like about it.
Here are some more examples using it:
;; Basically FIRSTN
;; Get the first 10 items in a list
(iterate ((item in list)
(i from 0 below 10))
(collect y))
;; Sort of GETL.
;;
(iterate ((prop on plist by cddr))
(when (memq (car prop) properties-to-collect)
(collect prop)))
;; Return a left hand to match left-hand-to-match
;; or error if couldn't find one.
(iterate ((left in left-hands)
(right in right-hands))
(when (eq left left-to-match)
(return right))
(finally (error "Could find a right hand.")))
∂04-Feb-86 1556 DLW@SCRC-STONY-BROOK.ARPA loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Feb 86 15:56:42 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 409938; Tue 4-Feb-86 18:56:24-EST
Date: Tue, 4 Feb 86 18:56 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: loop macro
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12180763116.BABYL@C.CS.CMU.EDU>
Message-ID: <860204185625.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 4 Feb 1986 17:10 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
3. The functionality of LOOP is fine, modulo some small details, but the
cute English-like syntax should be replaced with something more Lispy.
Specifically, parentheses should be used to group the arguments
controlling the various major options rather than doing this with
connecting words like "by", "until", and "whereas".
This is what we used to call the "new new style DO". Back in the late
70's, Alan Bawden experimented extensively with this idea, and had a
macro called DOO that was around for a while. Our conclusion was that
in order to get a reasonable level of functionality, you needed such a
maze of parentheses that the construct was extremely confusing and
promoted bad style. Possibly the reason that your suggestion "went
nowhere" is that people who tried to follow it up ran into the same
problems.
People in this
group feel pretty strongly that the little pseudo-sentences people end
up writing in the LOOP syntax are extremely confusing and promote bad
style. Things that aren't English shouldn't look like English.
Perhaps we should not be using WHEN as the name of a special form, on
the grounds that it looks like English but isn't English, and we should
stick with names like CDAR and MAKUNBOUND and HAIPART.
I agree that some uses of LOOP are confusing. But I disagree with the
analysis that any construct with embedded keywords must lead to
confusing programs. The problems that you see with the use of LOOP are
not inherent in the basic idea of LOOP, but rather a consequence of some
of the details of the present LOOP design. We believe that we can come
up with a keyword-oriented proposal that has the functionality that is
needed and is clear, but solves a lot of the problems of the existing
LOOP.
It sounds like you're in group 3 because you've seen a keyword-oriented
proposal that you don't like, but you have not yet seen any
non-keyword-oriented proposal at all. I hope we'll all get an
opportunity to compare and contrast a better keyword-oriented proposal
with someone's best shot at a non-keyword-oriented proposal, before
we come to a consensus on what Common Lisp should do.
We've been talking about a revised LOOP proposal for some time now. I
think the main reason we haven't made progress on it is the same
"exhaustion" that we discussed at the recent meeting. If everyone's
recovered sufficiently from the previous go-arounds, maybe it's time to
get moving on this again.
∂04-Feb-86 1651 snyder@hplsny Re: loop macro
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 4 Feb 86 16:51:35 PST
Received: from hplsny by hplabs.ARPA ; Tue, 4 Feb 86 16:50:26 pst
Received: by hplsny ; Tue, 4 Feb 86 16:48:22 pst
From: Alan Snyder <snyder@hplsny>
Message-Id: <8602050048.AA01118@hplsny>
Date: Tuesday, February 4, 1986 16:48:14
Subject: Re: loop macro
To: DLW@SCRC-QUABBIN.ARPA
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 4-Feb-86 18:56:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
It sounds like you're in group 3 because you've seen a keyword-oriented
proposal that you don't like, but you have not yet seen any
non-keyword-oriented proposal at all. I hope we'll all get an
opportunity to compare and contrast a better keyword-oriented proposal
with someone's best shot at a non-keyword-oriented proposal, before
we come to a consensus on what Common Lisp should do.
We have a loop macro proposal that is parenthesized. (It would be misleading
to call it non-keyword-oriented, because it uses keyword symbols to name the
parenthesized clauses!) It doesn't do everything the Zetalisp loop macro
does, nor does it incorporate all of the speculated improvements, but it's a
start. The description is a 23 page printed document. If you'd like a copy,
send your USmail address to:
mingus@hplabs.arpa
and ask for
STL-85-04 "A Loop Macro for Common Lisp"
We also have an implementation in Common Lisp that we could probably make
available if there is interest.
-------
∂04-Feb-86 1722 FAHLMAN@C.CS.CMU.EDU loop macro
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Feb 86 17:21:55 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 4 Feb 86 20:23:33-EST
Date: Tue, 4 Feb 1986 20:23 EST
Message-ID: <FAHLMAN.12180798298.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sean@λcadre.dsl.pittsburgh.edu (Sean McLinden)λ
Cc: common-lisp@SU-AI.ARPA
Subject: loop macro
In-reply-to: Msg of 4 Feb 1986 17:33-EST from sean at cadre.dsl.pittsburgh.edu (Sean McLinden)
Sean,
Unless I am confusing it with somehting else, the DePaul version of LOOP
depended on flavors and therefore was non-portable. (CMU's portable
flavor package never worked quite right, as you know best of all, and
with the departure of Steve handerson is no longer being worked on or
maintained, so nobody should depend on this.) Have you removed these
dependencies? I believe that they were mostly gratuitous.
-- Scott
∂04-Feb-86 1753 liz@brillig.umd.edu Re: loop macro
Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 4 Feb 86 17:52:03 PST
Received: by brillig.umd.edu (5.9/4.7)
id AA10539; Tue, 4 Feb 86 20:52:42 EST
Message-Id: <8602050152.AA10539@brillig.umd.edu>
To: common-lisp@SU-AI.ARPA
Subject: Re: loop macro
In-Reply-To: Your message of 4 Feb 86 15:50 PST.
<860204-155111-2418@Xerox>
Date: 04 Feb 86 20:52:41 EST (Tue)
From: Liz Allen <liz@brillig.umd.edu>
From: Gregor.pa@Xerox.COM
I think I prefer "lispy" iteration macros. Here is an
example of what I mean by a lispy iteration macro:
;; Return a list of the items in list-of-items
;; which pass the test TEST.
(iterate ((item in list-of-items))
(when (test item)
(collect item)))
I once worked with a looping macro that looked like that -- with
lots of nested parens. The main problem with it is that, when you
look at the code, you tend to think that the (when ...) up there
is a function call rather than part of some loop. It's too context
dependent and rather confusing.
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
3. The functionality of LOOP is fine, modulo some small
details, but the cute English-like syntax should be replaced
with something more Lispy. Specifically, parentheses should
be used to group the arguments controlling the various
major options rather than doing this with connecting words
like "by", "until", and "whereas". People in this group
feel pretty strongly that the little pseudo-sentences people
end up writing in the LOOP syntax are extremely confusing
and promote bad style. Things that aren't English shouldn't
look like English.
The mention of connecting words kind of puzzles me (and at the same
time helps me to understand the Lisp Machine loop macro). Our for
macro doesn't seem to need them (though it does use "by" and "until").
To explain how this works, let me give for's basic syntax:
(for [ let <let-var>* ]* ; <let-var> is <var> or (<var> <init>)
[ initially <form>* ]*
[ <iteration-spec>* ]* ; in, on, from, bind, being, etc
[ eachtime <form>* ]*
[ <termination-spec>* ]* ; while <form>* or until <form>*
[ <conditiion-spec>* ]* ; when <form>* or unless <form>*
[ <body-key> <form>* ] ; <body-key> is do, collect, etc
[ finally <form>* ] )
(I'll admit that not all of those *'s up there make a lot of sense
-- to understand them, imagine implicit progn's around them all.)
Each of those clauses stand alone -- there's no need to connect
them. In fact, you tend to think of the syntax as being "(for
<clause>*)". The from keyword does take by and to, but those are
part of the from clause. If the for was extended to handle more
than one body, then some of this neatness might disappear since
the when's and unless's would be associated with the next body
clause -- you'd want to indent the body clause more than the other
clauses and then the nice equality of clauses would not be as
strong... But, even then, you wouldn't need to add connectors.
I'm not trying to say that Common Lisp should necessarily adopt
the Maryland for as its looping construct. I just trying to say
that there ought to be some way to get rid of the concept of
connecting words without having to put parens around all the
clauses... Can the syntax for the Lisp Machine Loop be simplified
along these lines without losing big?
-Liz
∂04-Feb-86 1811 FAHLMAN@C.CS.CMU.EDU loop macro
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Feb 86 18:10:44 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 4 Feb 86 21:08:58-EST
Date: Tue, 4 Feb 1986 21:08 EST
Message-ID: <FAHLMAN.12180806565.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: loop macro
In-reply-to: Msg of 4 Feb 1986 18:56-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Dan,
First, you are right that my strong negative feelings were inspired by
the current LOOP stuff -- a fair amount of experience trying to read
loopy code and a very modest experience trying to write things in it. I
believe that the problem is a direct consequence of the cute
English-like syntax, but I'll try to keep an open mind in considering
anything new that you folks come up with. It's not inconceivable that
the real problems lie elsewhere. Of course, I can't speak for the
millions of other loop-haters in the world.
Second, I think that you misunderstood what I was suggesting as a remedy
for LOOP. While I don't remember Bawden's old DOO thing, I was not
suggesting that we flush all keywords and let levels of parentheses do
all the work. The existing DO construct goes just about as far in this
direction as it is wise to go, plus a bit. What I was advocating is
something very much like the sort of thing that Alan Snyder and Gregor
have just suggested, or like the package from PSL that was discussed
on the iteration list some time ago. (I'm not sure whether the H-P
proposal is the same as this.)
Just as I have no problem with the use of function names like When, I
have no problem with an iteration construct that uses mnemonic
English-like names or keywords to INTRODUCE various clauses. My problem
is with the English-like syntax, not with English-like vocabulary. If a
clause like Collect or Sum has arguments or some sort of body, Lisp
provides a perfectly good method for delimiting such a clause:
parentheses. To use little "glue" words like "from" and "until" to
stick such clauses together in this one part of the language and nowhere
else is what I object to. And since the syntax of this English-like
stuff is much more restricted than real English is, I find it very hard
to remember which little words are going to stick which arguments to
which operators. Yes, sometimes you can "read" loopy code aloud and it
says just what it is going to do, but other times the best code is not
the code that proudces the best approximation to grammatical English
when read as a sentence.
-- Scott
∂04-Feb-86 1826 FAHLMAN@C.CS.CMU.EDU loop macro
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Feb 86 18:26:16 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 4 Feb 86 21:22:08-EST
Date: Tue, 4 Feb 1986 21:21 EST
Message-ID: <FAHLMAN.12180808891.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: loop macro
In-reply-to: Msg of 4 Feb 1986 18:56-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
One last point -- upon looking more closely at the examples Gregor sent,
I notice that there is still a lot of infix stuff, which is unfortunate.
In a Lisp system I'd much rather see
(iterate (members-of x list) ...)
than
(iterate (x in list) ...)
But that much is negotiable.
-- Scott
∂04-Feb-86 1954 sean@cadre.dsl.pittsburgh.edu Re: loop macro
Received: from CADRE.DSL.PITTSBURGH.EDU by SU-AI.ARPA with TCP; 4 Feb 86 19:53:59 PST
Received: by PITTSBURGH.EDU (5.31/5.14)
id AA29262; Tue, 4 Feb 86 22:54:05 EST
Date: Tue, 4 Feb 86 22:54:05 EST
From: sean@cadre.dsl.pittsburgh.edu (Sean McLinden)
Message-Id: <8602050354.AA29262@PITTSBURGH.EDU>
To: Fahlman@c.cs.cmu.edu
Subject: Re: loop macro
Cc: common-lisp@su-ai.arpa
Scott:
The DePaul Common Lisp LOOP macro does not depend upon FLAVORS. It
did depend upon some knowledge of the Spice compiler but those were
trivial to replace. I have gotten it to compile and run on two other
versions of Common Lisp (non-Perq), so far, without trouble.
Sean
∂05-Feb-86 0616 FAHLMAN@C.CS.CMU.EDU loop macro
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Feb 86 06:16:40 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 5 Feb 86 09:17:49-EST
Date: Wed, 5 Feb 1986 09:17 EST
Message-ID: <FAHLMAN.12180939240.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sean@λcadre.dsl.pittsburgh.edu (Sean McLinden)λ
Cc: common-lisp@SU-AI.ARPA
Subject: loop macro
In-reply-to: Msg of 4 Feb 1986 22:54-EST from sean at cadre.dsl.pittsburgh.edu (Sean McLinden)
Sean,
In that case, if Miller is willing and if there are no legal
complications with MIT over copyright issues, this would be an excellent
thing to make available to the community. We can distribute it from
here, along with other portable stuff, if you like. I'm hoping that ISI
will be taking over the job of librarian soon, but in the meantime I've
assigned someone here to clean up our library directory and separate out
the perq-specific stuff.
-- Scott
∂05-Feb-86 0721 gls@THINK-AQUINAS.ARPA Re: loop macro
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 5 Feb 86 07:21:02 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 5 Feb 86 10:21:21 est
Date: Wed, 5 Feb 86 10:22 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: loop macro
To: Gregor.pa@Xerox.COM, BSG@SCRC-STONY-BROOK.ARPA
Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <860204-155111-2418@Xerox>
Message-Id: <860205102236.3.GLS@THINK-DESIDERIUS.ARPA>
Date: 4 Feb 86 15:50 PST
From: Gregor.pa@Xerox.COM
I think I prefer "lispy" iteration macros. Here is an example of what I
mean by a lispy iteration macro:
;; Return a list of the items in list-of-items
;; which pass the test TEST.
(iterate ((item in list-of-items))
(when (test item)
(collect item)))
I would like to note that the implementation of such an iteration macro
is one of the reasons that FLET and LABELS were included. The expansion
of (ITERATE ((ITEM IN LIST-OF-ITEMS)) body) might look like
(DO ((#:G0001 LIST-OF-ITEMS (CDR #:G0001))
(#:G0002 '()))
((NULL #:G0001) #:G0002)
(FLET ((COLLECT (X) (SETQ #:G0002 (NCONC #:G0002 (LIST X)))))
(DECLARE (INLINE COLLECT))
body))
Of course, the FLET would need to define all kinds of collectors that might
be needed, including MAXIMIZE, SUM, and so on; this leaves a problem as to
what the initial value for the result should be, in case the collector is
never called. One can do better by groveling through the body, of course.
Yuk. Anyway, MACROLET is useful if some collector needs special syntax.
--Guy
∂05-Feb-86 0908 gls@THINK-AQUINAS.ARPA Re: loop macro
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 5 Feb 86 09:00:25 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 5 Feb 86 12:00:36 est
Date: Wed, 5 Feb 86 12:01 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: loop macro
To: Gregor.pa@Xerox.COM, BSG@SCRC-STONY-BROOK.ARPA
Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <860204-155111-2418@Xerox>
Message-Id: <860205120150.4.GLS@THINK-DESIDERIUS.ARPA>
Okay, now here is a different perspective on the LOOP problem. I will play
devil's advocate here and claim that the main purpose of LOOP is to
duplicate the functionality of the sequence functions. Indeed, when
illustrating uses of LOOP we tend to pick as examples things that are single
sequence functions, which only gives me extra confidence that Common Lisp
has captured a useful set of primitive iteration operations in these
sequence functions. Here follows renderings of Gregor's examples in this
manner. (I don't mean to pick on Gregor; rather, he has done us the great
service of providing a few examples for discussion, and I'm discussing
them.)
;; Return a list of the items in list-of-items
;; which pass the test TEST.
(iterate ((item in list-of-items))
(when (test item)
(collect item)))
(remove-if-not #'test list-of-items)
;; Basically FIRSTN
;; Get the first 10 items in a list
(iterate ((item in list)
(i from 0 below 10))
(collect y))
(subseq list 0 10)
;; Sort of GETL.
;;
(iterate ((prop on plist by cddr))
(when (memq (car prop) properties-to-collect)
(collect prop)))
This one is indeed hard to do with sequence functions (because a
property list is not uniform). Instead I shall write a DO loop:
(do ((prop plist (cddr prop))
(result '() (if (memq (car prop) properties-to-collect)
----------------
(cons prop result)
----- -------
result)))
--------
((null prop) (nreverse result)))
-----------------
In this case the simple word "collect" certainly has captured a
common pattern of use (the parts underlines above), and so I cannot
deny that the iterate/collect syntax is more concise in this case.
;; Return a left hand to match left-hand-to-match
;; or error if couldn't find one.
(iterate ((left in left-hands)
(right in right-hands))
(when (eq left left-to-match)
(return right))
(finally (error "Could find a right hand.")))
(let ((pos (position left left-hands :test #'eq)))
(if pos
(elt right-hands pos)
(error "Could find a right hand."))) ;[Sic]
Because of their small size, these examples may not be convincing to
everyone. As additional evidence, here are some more complex examples of
uses of LOOP, taken from the Symbolics documentation (Volume 2: Reference
Guide to Symbolics-Lisp, March 1985):
Page 213:
(loop for x in list
collect (foo x) into foo-list
collect (bar x) into bar-list
collect (baz x) into baz-list
finally (return (list foo-list bar-list baz-list)))
(list (mapcar #'foo list)
(mapcar #'bar list)
(mapcar #'baz list))
Page 217:
(loop for x in l
when (atom x)
when (memq x *distinguished-symbols*)
do (process1 x)
else do (process2 x) ;[Sic--indentation bug!]
else when (memq (car x) *special-prefixes*)
collect (process3 (car x) (cdr x))
and do (memorize x)
else do (process4 x))
(mapcan #'(lambda (x)
(cond ((atom x)
(if (memq x *distinguished-symbols*)
(process1 x)
(process2 x))
nil)
((memq (car x) *special-prefixes*)
(prog1 (list (process3 (car x) (cdr x))) (memorize x)))
(t (process4 x) nil)))
l)
Finally, here are a few examples taken from actual code. These first few
are taken from the Symbolics implementation of FORMAT (I hope Symbolics
won't mind my quoting a few lines of code for academic "review purposes").
I'm more or less just going to take the first several loops I come to:
(LOOP FOR I FROM OLD-FILL-POINTER BELOW NEW-FILL-POINTER
DO (ASET #\SP FORMAT-STRING I))
(fill format-string #\sp :start old-fill-pointer :end new-fill-pointer)
(LOOP FOR I FROM CTL-INDEX BELOW (OR TEM CTL-LENGTH) DO
(FUNCALL *FORMAT-OUTPUT* ':TYO (SYS:CL-CHAR-CODE (AREF CTL-STRING I))))
(map nil #'(lambda (x) (funcall *format-output* ':tyo (sys:cl-char-code x)))
(subseq ctl-string ctl-index (or tem ctl-length)))
(LOOP FOR X = (ABS ARG) THEN (// X BASE)
COUNT T
UNTIL (< X BASE))
This isn't operating on sequences, so I will render this as a DO loop:
(do ((x (abs arg) (// x base))
(n 0 (+ n 1)))
((< x base) n))
(LOOP FOR DIVISOR = (↑ BASE (1- NDIGITS)) THEN (// DIVISOR BASE)
DO (FUNCALL *FORMAT-OUTPUT* ':TYO (+ (// ARG DIVISOR) #/0))
UNTIL (= DIVISOR 1)
DO (SETQ ARG (\ ARG DIVISOR))
(WHEN (ZEROP (\ (DECF NDIGITS) 3))
(FUNCALL *FORMAT-OUTPUT* ':TYO COMMACHAR)))
Again, sequences are not involved here, so I use a DO loop.
(do ((DIVISOR (↑ BASE (1- NDIGITS)) (// DIVISOR BASE)))
(())
(FUNCALL *FORMAT-OUTPUT* ':TYO (+ (// ARG DIVISOR) #/0))
(when (= DIVISOR 1) (return))
(SETQ ARG (\ ARG DIVISOR))
(WHEN (ZEROP (\ (DECF NDIGITS) 3))
(FUNCALL *FORMAT-OUTPUT* ':TYO COMMACHAR)))
(LOOP REPEAT WIDTH
DO (SEND *FORMAT-OUTPUT* ':TYO OVERFLOW-CHAR))
(dotimes (j width)
(declare (ignore j))
(SEND *FORMAT-OUTPUT* ':TYO OVERFLOW-CHAR))
(LOOP FOR I FROM 0
FOR X IN LIST
DO (ASET X ARRAY I))
(replace array x)
Now here are some examples taken from a microcode assembler written at
Thinking Machines:
(LOOP FOR DELAYED-FUNCTION IN *DELAYED-ASSEMBLY-FUNCTIONS*
FOR SYMBOL = (GET-DELAYED-ASSEMBLY-SYMBOL DELAYED-FUNCTION)
DO (SETF (SYMEVAL SYMBOL) NIL))
(dolist (delayed-function *delayed-assembly-functions*)
(setf (symeval (get-delayed-assembly-symbol delayed-function)) nil)
[I don't know why SET was not used there.]
;; if there were any MMCALLs, they must be removed.
(SETQ *ALL-MMCALLS* (LOOP FOR CALL-ITEM IN *ALL-MMCALLS*
FOR CALLING-LOCATION = (SECOND CALL-ITEM)
FOR CALLING-INSTR = (AREF INSTR-FROM-LOC CALLING-LOCATION)
WHEN (NOT (<= START-INSTR CALLING-INSTR STOP-INSTR))
COLLECT CALL-ITEM))
(setq *all-mmcalls*
(remove-if-not #'(lambda (call-item)
(let* ((calling-location (second call-item))
(calling-instr (aref instr-from-loc calling-location)))
(<= start-instr calling-instr stop-instr)))
*all-mmcalls*))
(LOOP FOR INSTR FROM START-INSTR BELOW (1+ STOP-INSTR) DO
;; smash the instruction at this location
(SETF (AREF INSTR-AFTER-INLINE-MACROEXPAND INSTR) NIL)
(SETF (AREF INSTR-BEFORE-INLINE-MACROEXPAND INSTR) NIL)
(progn (fill instr-after-inline-macroexpand nil :start start-instr :end (1+ stop-instr))
(fill instr-before-inline-macroexpand nil :start start-instr :end (1+ stop-instr)))
(LOOP FOR (VARIABLE-NAME TYPE . REST) IN *UC-CS-ELEMENTS*
COLLECTING VARIABLE-NAME)
(mapcar #'car *uc-cs-elements*)
[Admittedly the destructuring gives one a nice picture of what's going on.]
In a fair amount of recent programming in Common Lisp, I have found that
extensive use of MAP, REDUCE, and REMOVE-IF eliminates the need for a
lots of explicit loops. Certainly the code generates some intermediate
list structure that could be eliminated. I would very much like to see
compilers that can, in certain easy cases, open-code calls to a few of
these sequence functions and jam loops together. Here are examples of code
originally rendered in that style, along with a translations using LOOP:
(reduce #'union (mapcar #'xapping-exceptions args) :initial-value '())
(LOOP FOR X IN ARGS UNIONING (XAPPING-EXCEPTIONS X))
[This assumes I manage to define a new collector UNIONING
(not supplied in Symbolics LOOP).]
(LOOP FOR X IN ARGS
FOR RESULT = '() THEN (UNION RESULT (XAPPING-EXCEPTIONS X))
FINALLY (RETURN RESULT))
(reduce #'intersection
(mapcar #'xapping-domain
(remove-if #'xapping-infinite args)))
(LOOP FOR X IN ARGS
FOR RESULT = T
UNLESS (XAPPING-INFINITE X)
WHEN (EQ RESULT T)
DO (SETQ RESULT X)
ELSE DO (SETQ RESULT (INTERSECTION RESULT X)))
Can anyone else render these examples more elegantly using LOOP? I'm not
sure I have demonstrated the point I set out to prove, but I think I have
provided some more interesting examples to discuss.
--Guy
∂05-Feb-86 1501 shebs%utah-orion@utah-cs.arpa GLS replacements for LOOP
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 5 Feb 86 14:59:31 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA01868; Wed, 5 Feb 86 16:00:27 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA03174; Wed, 5 Feb 86 16:00:24 MST
Date: Wed, 5 Feb 86 16:00:24 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8602052300.AA03174@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: GLS replacements for LOOP
I really liked the examples Guy presented - I've long had the feeling
that some of the sequence functions could be really really useful if
only I knew how to use them! And although I've translated PSL's FOR
macro into portable CL, it only seems to get used for compatibility with
old PSL code. So I've sort of drifted from camp 3 to camp 1.
There are a couple problems with using tricky sequence functions etc
instead of generalized loop constructs. Loop macros are frequently
easier to modify - I can just stick in another clause. The before
and after equivalent sequence function calls may be quite dissimilar.
There are more serious questions of efficiency. Loops macros tend
to expand into Fortran-like code. A large proportion of the loops
in PSL's runtime system are written using a version of FOR that totally
opencodes; I believe the same is true of Zetalisp. On the other hand,
this is a little harder to do with the sequence functions. Guy's example of
a multiple-iterator loop turning into (list (mapcar ...) (mapcar ...) ...),
could be fully opencoded, but that would take a pretty aggressive compiler
that had just seen (proclaim '(optimize (speed 3) (safety 0))).
Is anybody's compiler "sufficiently good" to turn sequence function
usages into code as efficient as LOOP produces?
stan
∂05-Feb-86 1522 @MC.LCS.MIT.EDU:Soley@MC.LCS.MIT.EDU Re: loop macro
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Feb 86 15:20:23 PST
Received: from CHERRY.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 FEB 86 17:47:19 EST
Date: Wed, 5 Feb 86 17:46 EST
From: Soley@MIT-MC.ARPA
Subject: Re: loop macro
To: Gregor.pa@Xerox.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860204-155111-2418@Xerox>
Message-ID: <860205174634.3.SOLEY@MIT-CHERRY.ARPA>
Date: 4 Feb 86 15:50 PST
From: Gregor.pa@Xerox.COM
Subject: Re: loop macro
In-reply-to: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>'s message
of Tue, 4 Feb 86 16:38 EST
To: BSG@SCRC-STONY-BROOK.ARPA
cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Message-ID: <860204-155111-2418@Xerox>
I think I prefer "lispy" iteration macros. Here is an example of what I
mean by a lispy iteration macro:
;; Return a list of the items in list-of-items
;; which pass the test TEST.
(iterate ((item in list-of-items))
(when (test item)
(collect item)))
Parens do not a Lisp code make. This particular example, for instance,
isn't any "lispier" than the equivalent LOOP construction; the
expression "(collect item)" is CERTAINLY not a call to some new function
COLLECT, is it?
-- Richard
∂05-Feb-86 1522 AI.BOYER@MCC.ARPA loop speed
Received: from MCC.ARPA by SU-AI.ARPA with TCP; 5 Feb 86 15:18:01 PST
Date: Wed, 5 Feb 1986 15:56 CST
Message-ID: <AI.BOYER.12181022722.BABYL@MCC.ARPA>
From: AI.BOYER@MCC.ARPA
To: common-lisp@SU-AI.ARPA
Subject: loop speed
As Guy Steele recently pointed out, it is certainly the case
that constructs written with loop can often be recoded using
the mapping functions. I stopped using the mapping
functions a long time ago in Interlisp in large part because
I found that I.S.OPR expressions, the inspiration for loop,
ran significantly faster. Has the situation changed much?
I certainly have not made a careful comparison of the matter
recently, but I just timed the two following functions,
after compilation:
(defun remove-if-test (l)
(remove-if #'atom l))
(defun loop-test (l)
(loop for x in l unless (atom x) collect x))
Loop-test runs 3 to 4 times faster than remove-if-test in
Symbolics Common Lisp on a 3640 on long lists of nils.
Inspired by the fact that Guy can recode many uses of loop
into maps, perhaps someone can write a compiler that can
take maps back to loops for compilation efficiency!
∂05-Feb-86 1529 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: eval'd macros (the other point of view)
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 5 Feb 86 15:28:30 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000388; 5 Feb 86 16:55 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Wed, 5 Feb 86 16:56:03 GMT
Message-Id: <Wed Feb 5 16:56:03 1986 @ aiva.edinburgh.ac.uk>
To: Fahlman@c.cs.cmu.edu, KMP@scrc-stony-brook.arpa
Subject: Re: eval'd macros (the other point of view)
Cc: common-lisp@su-ai.arpa
Having macros expanded when the defun is first seen offers the nice feature
that you can't easily break functions you've already written as you enter a
debugging phase.
You also can't FIX functions you've already written by changing the
macros they call. You now have to go back and find every last function
that calls FOO, and re-expand it to do the right thing, assuming that
you've got the source handy. Things that I'm sure are right and that I
don't want to break are usually already compiled.
One advantage of having the interpreter expand macros when it sees a DEFUN is
that it would reduce the differences between the compiler and the interpreter.
(Of course, this may be exactly the kind of difference you want to preserve.)
And, as has been mentioned, you would then know that all macro calls had been
expanded, not just those that had been evaluated. You could still fix these
functions by changing the macro if the macro expansion was memoized in such a
way that it noticed when the macro was redefined. Similarly, if you didn't
want to break functions when the macro was redefined, some way of inhibiting
their noticing the redefinition could be provided.
-- Jeff
∂05-Feb-86 1536 Fitch%cs.ucl.ac.uk@Cs.Ucl.AC.UK LISP standardisation
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 5 Feb 86 15:34:36 PST
Date: Wed, 5 Feb 86 22:27:57 GMT
From: Fitch%cs.ucl.ac.uk@cs.ucl.ac.uk
To: common-lisp@su-ai.arpa
cc: ma←jap%ux63.bath.ac.uk@cs.ucl.ac.uk
Subject: LISP standardisation
A statement about the European standardisation effort on LISP.
A committee, called the EuLISP committee, has met regularly since
September of last year to prepare a definition of LISP for presentation
to the respective national standards organisations of the members and
thence to ISO. Regular participants include Chailloux, Christaller,
Krumnack, Fitch, Padget, Pope, Queinnec and Steels. EuLISP is simply the
name of the committee; the name of the defined language will, we hope, be
ISO LISP. For convenience that name is used for the definition in the
rest of this message.
ISO LISP is a post Common LISP (CL) LISP, which is to say that it draws
on the experience of the CL definition and development effort, as well as
the experience of other LISP activities.
ISO LISP has a compact, identifiable kernel, which, in itself, will
correspond to the level 0 definition. The full ISO LISP will be defined
at several levels in two dimensions. Along one axis is the complexity of
the language, and along the other are the multiple levels of
programming environment support.
It is our intention to define the kernel such that Level (0,0) be very
simple and portable even to current micro-computers while Level (3,3) (or
more likely (3,2) or (3,1)) with less environment will have at least the
breadth and depth of CL as discussed in Steele et al. (Digital Press),
but this should by no means be read as a committment to correspond
exactly or completely (by extension or omission) with that document. CL
is certainly the major input to the definition, but it is not the only
one. Even now, CL, as laid down by Steele et al., is under review and
this fact alone makes such a committment unwise.
The EuLISP committee includes representatives of the implementors of two
LISP dialects widely used outside the United States, namely Le←LISP and
Cambridge LISP, in addition to large LISP users. The effect of this is
that the committee can take advantage of the lessons learnt over the
lives of these systems, whilst at the same time using them as an
environment for prototyping the new definition. Let it be clearly stated
that this is not an attempt to make either Cambridge LISP or Le←LISP or
some hybrid into a standard, but to evolve a new standard.
A fundamental part of the definition process includes a rationale for ISO
LISP and, incrementally, there will be a rationale for each major design
decision, such as why something is included, excluded or at variance in
some other way with existing dialects.
The EuLISP committee meets on the first Monday of each month and the
sessions are open. The next three meetings are scheduled as follows:
March 3 1986 - IRCAM (near Pompidou Centre), Paris.
April 7 1986 - INRIA, Sophia Antipolis (near Nice).
May 5 1986 - IRCAM, Paris.
Subsequent meetings will be arranged on a three month forward plan.
We are determined that the definition will be complete in twelve months
and in accordance with that aim, the draft level 0 definition will be
produced by 1 June 1986. It is also expected that prototype
implementations will conform to that definition very close to that date.
The monthly meetings are first and foremost for coordination, review and
setting the next group of objectives. The remaining time is allotted
to technical issues, but for the most part, such details are discussed on
electronic mail, to which end there is a mailing list:
{seismo,decvax}!mcvax!inria!eulisp at INRIA (Paris).
Interested parties should mail Chailloux at that address (...!inria!chailloux)
to be added.
∂05-Feb-86 1650 hpfclp!diamant@hplabs.ARPA Re: eval'd macros (the other point of view)
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Feb 86 16:49:34 PST
Received: by hplabs.ARPA ; Wed, 5 Feb 86 16:49:03 pst
Date: Wed, 5 Feb 86 16:49:03 pst
From: hpfclp!diamant@hplabs.ARPA
To: hplabs!common-lisp@su-ai.ARPA
Subject: Re: eval'd macros (the other point of view)
From: David C. Plummer <hplabs!DCP@SCRC-QUABBIN.ARPA>
Subject: eval'd macros
Date: Mon, 3 Feb 1986 20:36 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
(defun fn () (mac)) ;==> FN
(defmacro mac () `'foo) ;==> MAC
(fn) ;==> ***Error***
...
In my
opinion, this should work without an error in the interpreter. Hacking
in the interpreter would be fairly awkward if it didn't. However, the
fourth paragraph on page 143 seems to give implementors permission to do
compiler-like macro expansion when a defun is first seen. I wouldn't
want to use such an implementation, but it probably is legal as the
manual currently stands.
I would like to second Kent Pitman's opinion. Maybe no one has mentioned
this objection because it is so obvious -- it is still very important.
I think that it is a bad idea to have the interpreter defer expansion of
macros because it is just one more case of differing interpreter and
compiler semantics. If I am to believe the statement regarding consistency
in the introduction of CLtL: "The definition of COMMON LISP avoids such
anomalies by explicitly requiring the interpreter and compiler to impose
identical semantics on correct programs so far as possible," then as Kent
suggests, the interpreter should not defer expansion because the compiler
is required not to.
If the system goes further and actually DOES compile
the defun, then I would consider it a user-interface bug that the
compiler doesn't tell the user that it couldn't find a function call
MAC.
(defun fn () (mac))
FN
(compile 'fn)
The following functions were referenced but don't seem defined:
MAC referenced by FN
FN
I also consider this to be a bad idea. Does this mean that COMPILE-FILE
will also do this? If so, then it will generate warnings on correct code.
In fact, since there is no forward declaration facility, some code (mutually
recursive fuctions) would necessarily generate warnings on correct code.
Alternately, are you suggesting that COMPILE should generate different
warnings than COMPILE-FILE? In this case, while you are not strictly changing
the semantics of correct code (since it is a warning instead of an error),
you are violating the intent of the consistency argument.
The problems with compiler/interpreter semantics are bad enough in packages
that we should try to avoid unnecessarily propagating them in other areas.
John Diamant
Fort Collins Systems Division UUCP: {ihnp4,hplabs}!hpfcla!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfcla@hplabs
Fort Collins, CO
∂05-Feb-86 1650 willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA lexical scope & program development
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 5 Feb 86 16:48:35 PST
Received: from tektronix by csnet-relay.csnet id ak16364; 5 Feb 86 19:33 EST
From: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA
To: common-lisp@su-ai.ARPA
Cc: willc%tektronix.csnet@CSNET-RELAY.ARPA
Received: from tekchips by tektronix with smtp ; 5 Feb 86 12:34:05 PST
Comment: Message received over unauthenticated port at tektronix
Received: by tekchips (5.31/5.14), id AA00785; Wed, 5 Feb 86 12:35:28 PST
Message-Id: <8602052035.AA00785@tekchips>
Subject: lexical scope & program development
Date: 05 Feb 86 12:35:22 PST (Wed)
Date: Fri, 31 Jan 86 12:37 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
I believe that all the problems you've been talking about have to do
with the poor interaction between lexical scoping and incremental
programming. These poor interactions are discussed in the paper "The
Art of the Interpreter: Parts Zero, One, and Two" by Guy Steele and
Gerry Sussman. They are not incidental design flaws of Common Lisp;
they are part of the deep nature of lexical scoping. I don't think they
represent a "time bomb" in the language. They just show how lexical
scoping, itself, has problems when it comes to program development, when
used in this way....
People here who have constructed an incremental programming environment
for a lexically scoped language tell me that lexical scope was among the
least of their worries.
If a lexically scoped interactive language takes the point of view that
all unbound variables are really variables bound to locations in which
undefined values are stored (so that all definitions are viewed as
assignments rather than bindings), and variable fetches that yield
such values are trapped, then most of the problems cited in the
paper by Steele and Sussman go away. There remain needs for (1) temporary
assignments (as in the current MIT Scheme dynamic variable semantics);
(2) module facilities that can hide or expose variables (as in the Common
Lisp package system or MIT Scheme environments); and (3) debugging facilities
(as in a debugger).
A dynamically scoped top level only solves problem (1), and solves it only
for top level variables. Since (1) must be solved for lexical variables
anyway, a dynamically scoped top level is neither necessary nor useful.
The real problem with lexical scope and interactive program development
is that lexical scope is a hiding mechanism, and hiding hinders the
debugging process. It seems to me that the solution is a good debugger
that can expose the hidden, for example by allowing the programmer to
crawl through the environment of a closure and to evaluate code in any
environment that can be reached that way. (I realize that some compilers
don't keep enough information around to support such a debugger, or they
perform so much optimization that it's impractical, but in such a case
I'd say that it is the compiler, not lexical scope, that is incompatible
with interactive program development.)
William Clinger
willc@tektronix.csnet
Tektronix Computer Research Laboratory
∂05-Feb-86 1738 hpfclp!diamant@hplabs.ARPA intern
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Feb 86 17:34:52 PST
Received: by hplabs.ARPA ; Wed, 5 Feb 86 13:03:36 pst
Date: Wed, 5 Feb 86 13:03:36 pst
From: hpfclp!diamant@hplabs.ARPA
To: hplabs!common-lisp@su-ai.ARPA
Subject: intern
On page 172 of CLtL, the verb "intern" is defined. It is stated that one
action performed is setting the home package of a symbol which doesn't already
have one. My question is: does INTERN (the function) always "intern" (the
verb). Also, are there any other functions which "intern," such as import,
for instance. Specificially, should INTERN set the home package of an
uninterned symbol?
example:
(setq sym (gensym)) ; make an uninterned symbol
(import sym) ; make it available in the current package
; assuming import did not set the home package (is this a correct assumption?):
(intern (symbol-name sym))
; (note: intern takes a string, not symbol, argument)
; looks up (interns?) the symbol
; should intern set the home package?
; then consider:
(find-symbol (symbol-name sym))
; find-symbol is defined to be just like intern,
; but does not make a new symbol
; in this case it finds an existing symbol,
; so should find-symbol set the home package?
relevant material from CLtL
page 172
a symbol is interned in a package if
1) it is accessible in that package
2) its package cell is not NIL (any package may own it)
to intern a symbol in a package
1) is performed by the function INTERN
2) makes the symbol interned in the package, unless it already was
3) if the symbol was previously unowned (its package cell was NIL)
then the package it is being interned in becomes its owner
else the package cell is not changed
page 184
the function INTERN sets the package cell if it must create a new symbol,
but no mention is made of setting the package if it finds an existing
unowned symbol
page 185
the function FIND-SYMBOL is identical to INTERN except when no symbol is
found, in which case it returns NIL
page 186
the function IMPORT makes symbols "internal symbols" in a package
does this imply that they are interned in the package?
My feeling on this is that INTERN should set the home package if the symbol
currently has none, but that FIND-SYMBOL should not. If this is correct,
then the definition of FIND-SYMBOL on page 185 is misleading.
John Diamant
Fort Collins Systems Division UUCP: {ihnp4,hplabs}!hpfcla!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfcla@hplabs
Fort Collins, CO
∂05-Feb-86 1900 BSG@SCRC-STONY-BROOK.ARPA Re: loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Feb 86 18:59:51 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 410230; Wed 5-Feb-86 09:59:17-EST
Date: Wed, 5 Feb 86 10:08 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: loop macro
To: liz%brillig.umd.edu@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8602050152.AA10539@brillig.umd.edu>
Message-ID: <860205100800.8.BSG@CONCORD.SCRC.Symbolics.COM>
Date: 04 Feb 86 20:52:41 EST (Tue)
From: Liz Allen <liz@brillig.umd.edu>
The mention of connecting words kind of puzzles me (and at the same
time helps me to understand the Lisp Machine loop macro). Our for
macro doesn't seem to need them (though it does use "by" and "until").
To explain how this works, let me give for's basic syntax:
(for [ let <let-var>* ]* ; <let-var> is <var> or (<var> <init>)
[ initially <form>* ]*
[ <iteration-spec>* ]* ; in, on, from, bind, being, etc
[ eachtime <form>* ]*
[ <termination-spec>* ]* ; while <form>* or until <form>*
[ <conditiion-spec>* ]* ; when <form>* or unless <form>*
[ <body-key> <form>* ] ; <body-key> is do, collect, etc
[ finally <form>* ] )
I'm not trying to say that Common Lisp should necessarily adopt
the Maryland for as its looping construct. I just trying to say
that there ought to be some way to get rid of the concept of
connecting words without having to put parens around all the
clauses... Can the syntax for the Lisp Machine Loop be simplified
along these lines without losing big?
What are "let", "initially", "eachtime", "in", "on", "from", "bind", "being",
"finally", in your macro, if not connecting words, or am I totally confused?
∂05-Feb-86 1901 DLW@SCRC-STONY-BROOK.ARPA loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Feb 86 19:01:22 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 410289; Wed 5-Feb-86 10:49:34-EST
Date: Wed, 5 Feb 86 10:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: loop macro
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12180806565.BABYL@C.CS.CMU.EDU>
Message-ID: <860205104933.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
It sounds like what you're really saying isn't that you dislike keywords
in all cases, but that you dislike keywords when they aren't the first
element of a list. The main reason you cite is that it's inconsistent
with the rest of the language, which never does that.
This is a pretty good argument and it's mostly true. On the other hand,
I'm not sure it's completely true. Compare
(reduce #'+ seq :start 5 :end 7)
and
(loop for a from 4 below 7 do ..body..)
I'm not sure they're really all that different. The fact that LOOP uses
infix keywords, per se, doesn't make LOOP that different from the rest
of the language.
The thing that's more upsetting is
(loop for a from 4 below 7
for b from 7 do ..body..)
because there is a clear grouping between the elements in the first
"for" clause and the elements in the second "for" clause, but that
grouping is not expressed by parentheses. I think this is where the
existing LOOP starts to look inconsistent with the syntax of the rest of
the language. Because you've mentioned "little words as delimiters" in
some of your mail, I suspect that this is the real point of contention.
I agree that this is a drawback to the existing LOOP.
The most obvious way to try to repair this is to make the syntax look
more like DO, by having a bunch of iteration-specifying constructs at
the front of the form, followed by a body. This might look like the
schemes we've seen in recent mail.
However, this severely restricts the power of the construct. Here's the
most basic and obvious example that comes to my mind. One of our basic
requirements for LOOP was that it should be able to support the popular
repeat/until construct present in many of the Pascal-family languages,
in which the checking is done at the end of the loop rather than at the
beginning. For clarity, we felt that the predicate form ought to appear
syntactically following the body.
It's possible that this should be handled by simply telling the program
to write a (when <predicate> (return <form>)) in the body. We didn't
like this solution, because it seemed too much like a step backward from
DO back towards PROG. Part of the idea of DO was to get the basic
iteration control constructs separate from the body. After all, we
don't need the end-test part of DO at all; a similar when/return at the
beginning of the body would have the same effect.
We could add grouping without going so far as to force all clauses
to the front.
(loop (for a from 4 below 7)
(for b from 7)
(do ..body..)
(until ..pred..))
I think this might be an improvement. One problem is that we were
hoping to get rid of the "do" keyword entirely (Moon agrees with this),
but with this change, it's harder to see how to accomplish that.
Your argument about finding it "hard to remember which little words" is
something I can only partially agree with. One might just as well point
out that Common Lisp has many functions and special forms, and it's
often hard to remember their names. This sounds to me like a question
of the programming environment and the organization of the
documentation, more than a question of language design.
There's another LOOP feature that I consider quite valuable, and I also
think that the clauses-up-front-and-a-body syntax might be hard to
extent to handle. This is the "always" keyword and its friends.
(loop for e in list always <predicate-form-using-e>)
is more expressive than
(not (dolist (e list)
(when <predicate-form-using-e>
(return t))))
or
(not (find-if-not #'(lambda (e) <predicate-form-using-e>) list)
and it's also more general, because the range of iteration that LOOP can
express is so much more than just iterating over one sequence.
ALWAYS is strange because the predicate form is really the body, in some
sense, but we aren't just executing it for effect over and over. This
is why I'm not sure it fits into the clauses-up-front structure so well;
I think it would be sort of strange for the predicate form to live in
one of the clauses-up-front and for the body to be empty.
Since I'm getting into details, I should make quite clear that I do not
speak for Moon in the matter of LOOP. Our opinions on this topic
diverge much more than they do on most other topics.
One of my own strong feelings about LOOP that Moon does not share is
that we should get rid of the conditionals. I think Common Lisp has at
least enough basic conditional forms as it is, and having separate ones
for LOOP is beyond the pale. I am particularly grossed out by the idea
of having a "dangling ELSE" in Lisp. The present LOOP, like the
conventional languages, has the convention that such an ELSE binds to
the inner IF. This fits into Lisp just about as much as the concept of
"operator precedence", i.e. not at all.
The main reason for the conditionals is so that COLLECT clauses can be
executed conditionally. (I don't know for sure whether there are other
reasons for the conditionals.) The usual proposed solution is to make
COLLECT a regular Lisp macro, that communicates with an outer collector
macro via COMPILER-LET, making COLLECT a separate facility completely
orthogonal to LOOP. It seems clear to me that this is the right thing
to do. After all, suppose you want to write a program that does a
double recursion down a binary tree, and collects something as it goes?
LOOP can't handle this kind of iteration, but you still want COLLECT.
Yes, I know you can write your own LOOP iteration path, but what if you
think that nice, traditional, Lispy recursion is a simple and expressive
way to write your program?
These are just some of the traditional issues of LOOP redesign. There
are definitely others. I just wanted to give everyone some idea of the
kinds of things we've thought about.
∂05-Feb-86 2025 FAHLMAN@C.CS.CMU.EDU eval'd macros (the other point of view)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Feb 86 20:24:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 5 Feb 86 23:25:59-EST
Date: Wed, 5 Feb 1986 23:25 EST
Message-ID: <FAHLMAN.12181093659.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: hpfclp!diamant@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: eval'd macros (the other point of view)
In-reply-to: Msg of 5 Feb 1986 19:49-EST from hpfclp!diamant at hplabs.ARPA
I would like to second Kent Pitman's opinion. Maybe no one has mentioned
this objection because it is so obvious -- it is still very important.
I think that it is a bad idea to have the interpreter defer expansion of
macros because it is just one more case of differing interpreter and
compiler semantics. If I am to believe the statement regarding consistency
in the introduction of CLtL: "The definition of COMMON LISP avoids such
anomalies by explicitly requiring the interpreter and compiler to impose
identical semantics on correct programs so far as possible," then as Kent
suggests, the interpreter should not defer expansion because the compiler
is required not to.
Well, if we wanted everything to be ABSOLUTELY IDENTICAL between
compiled and interpreted code, except that the compiled code runs faster,
there would be no point in having an interpreter at all. The compiler,
in the name of efficiency, does certain things to the code that makes
debugging and incremental changes harder. For example, in most systems
you can't single-step code once it is compiled, and in some systems you
can't trace it. It would be nice if these things kept on working after
compilation, but it is hard to arrange this.
In Lisp we go to some trouble to allow you to redefine functions, even
after a lot of calls to those functions have been compiled. Those calls
see the new definition, whether it is compiled or interpreted. Macros
and inline functions get burned in and cannot later be changed without
finding all the calls and recompiling them. That's too bad, but it's
the price you pay for avoiding the overhead of a function call. (This
immutability is sometimes deliberately used to lock out later changes,
but that is fairly rare and could be handled by some specialized kind of
call.)
So we have to give up the ability to change macros (or define them after
the call) in compiled code, but to live without this ability in the
interpreter would be a tremendous pain. People who have written
macro-memoizing functions to speed up interpreters have generally gone
to a lot of trouble to put in some way of un-memoizing when a macro gets
redefined. I don't think I'd try to develop code in any system that
expanded all the macros at DEFUN time unless it included a very
well-engineered and transparent un-memoizing function.
I grant that if the interpreter waits until use before expanding a
macro, it would be easy to create a file of code that works interpreted
and errs out when you compile it. Any good compiler will make it very
clear what the problem is: "FOO being defined as a macro, earlier
assumed to be a function" or some such message, so it is not a treacherous
kind of incompatibility like some of the special/local stuff used to be.
So getting rid of this incompatibility is not nearly as important to me
as being able to fix up faulty macros while I am debugging.
-- Scott
∂05-Feb-86 2051 FAHLMAN@C.CS.CMU.EDU loop macro
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Feb 86 20:44:14 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 5 Feb 86 23:45:46-EST
Date: Wed, 5 Feb 1986 23:45 EST
Message-ID: <FAHLMAN.12181097258.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: loop macro
In-reply-to: Msg of 5 Feb 1986 10:49-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Dan,
From your recent message, it sounds like you and I are not so far apart
after all. It seems to me that with a bit of work, one could come up
with something that had all the functionality of the Zetalisp LOOP, but
with some parentheses to show you where one clause leaves off and
another starts instead of depending on a lot of syntactic analysis for
this. The H-P and/or PCL constructs might serve as a starting point,
but I'm not wedded to the idea of always putting the counters at the
start.
I'm sure if we all thought hard about it, we could find ways of dealing
with such potential warts as UNTIL and ALWAYS. Once you've got the
parens in there, things like COLLECT can be forms that are defined only
within the scope of a LOOP, but that can appear inside of Lisp
conditionals or other code.
If enough people like this idea, it would be worth the trouble of trying
to work out the details. As long as we're divided into the camps of
"English-like LOOP is the only acceptable way" and "Over my dead body",
there's not much point in messing with this, however.
-- Scott
∂05-Feb-86 2123 FAHLMAN@C.CS.CMU.EDU eval'd macros (the other point of view)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Feb 86 21:16:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 6 Feb 86 00:18:15-EST
Date: Thu, 6 Feb 1986 00:18 EST
Message-ID: <FAHLMAN.12181103172.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: hpfclp!diamant@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: eval'd macros (the other point of view)
In-reply-to: Msg of 5 Feb 1986 19:49-EST from hpfclp!diamant at hplabs.ARPA
(defun fn () (mac))
FN
(compile 'fn)
The following functions were referenced but don't seem defined:
MAC referenced by FN
FN
I also consider this to be a bad idea. Does this mean that COMPILE-FILE
will also do this? If so, then it will generate warnings on correct code.
In fact, since there is no forward declaration facility, some code (mutually
recursive fuctions) would necessarily generate warnings on correct code.
Alternately, are you suggesting that COMPILE should generate different
warnings than COMPILE-FILE? In this case, while you are not strictly changing
the semantics of correct code (since it is a warning instead of an error),
you are violating the intent of the consistency argument.
It is not incorrect to generate warnings on correct code. A warning
says that the compiler cannot prove that some code is incorrect, but
that it has spotted something that may be an error, gross inefficiency,
or something else the user might want to look at. Such warnings have
saved me hundreds of hours of debugging time, and I wouldn't want to do
without them. If you don't like them, most compilers let you turn them
off.
Yes, such warnings do tend to spook naive users who are compiling other
people's code. To suppress such warnings, Common Lisp does provide a
forward-declaration facility for functions: (declare (ftype...)) or
(declare (function ...)). I don't think that the Spice Lisp compiler
uses these declarations to suppress warnings, but it should.
In most implementations that I have seen, Compile-File lists at the end
of the file, as a sort of warning, any functions that were used but that
are not known to the compiler. A function generally becomes known
either by being present in the Lisp doing the compiling, by being
defined in a previously-compiled file, or by being defined somewhere in
the current file. Dumping this list is done at the end of a file just
so that the order of definitions within a file doesn't cause a lot of
spurious warnigns to appear. Co-recursive functions can be defined with
no problem, etc.
I don't much care whether Compile warns me about undefined functions or
not. Since Compile-File waits till the end of the file to complain
about unknown functions and special variables, it seems consistent to
keep quiet about this when compiling functions one-by-one.
-- Scott
∂05-Feb-86 2310 zorn@renoir.berkeley.edu Interest in "large" Common Lisp Programs
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 5 Feb 86 21:42:29 PST
Received: by ucbvax.berkeley.edu (5.45/1.9)
id AA09476; Wed, 5 Feb 86 20:42:29 PST
Received: by renoir.berkeley.edu (5.44/5.16)
id AA08869; Wed, 5 Feb 86 16:41:58 PST
Message-Id: <8602060041.AA08869@renoir.berkeley.edu>
To: common-lisp@su-ai.arpa
Cc: larus@dali.berkeley.edu, taylor@kim.berkeley.edu,
hilfingr@renoir.berkeley.edu, ho@ernie.berkeley.edu,
zorn@renoir.berkeley.edu
Subject: Interest in "large" Common Lisp Programs
Date: 05 Feb 86 16:41:49 PST (Wed)
From: Benjamin Zorn <zorn@renoir.berkeley.edu>
The SPUR Project at UC Berkeley is building a RISC multiprocessor that
will run a multiprocessor version of Common Lisp. We are currently
evaluating the architectural decisions using a simulator for the
machine and are very interested in obtaining "large" Common Lisp
programs that would be considered significant applications by people
in the field. As we are currently concerned with the performance of
Common Lisp without extensions, programs that don't use an object
system are preferable to ones that do. Any pointers would be greately
appreciated.
Ben Zorn
Jim Larus
Kinson Ho
George Taylor
Paul Hilfinger
UC Berkeley
(e-mail to zorn@renoir.berkeley.edu)
∂06-Feb-86 0507 DLW@SCRC-STONY-BROOK.ARPA lexical scope & program development
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 Feb 86 05:07:26 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 411159; Thu 6-Feb-86 08:06:58-EST
Date: Thu, 6 Feb 86 08:09 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: lexical scope & program development
To: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA
cc: willc%tektronix.csnet@CSNET-RELAY.ARPA
In-Reply-To: <8602052035.AA00785@tekchips>
Message-ID: <860206080937.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
I don't see how any of this addresses the original issue that I was
discussing. Unbound variables have nothing to do with it. Did
you read DCP's messages?
∂06-Feb-86 0514 DLW@SCRC-STONY-BROOK.ARPA Re: loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 Feb 86 05:14:26 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 411167; Thu 6-Feb-86 08:13:59-EST
Date: Thu, 6 Feb 86 08:16 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: loop macro
To: liz%brillig.umd.edu@MIT-MC.ARPA
cc: BSG@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860205100800.8.BSG@CONCORD.SCRC.Symbolics.COM>
Message-ID: <860206081637.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 5 Feb 86 10:08 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Date: 04 Feb 86 20:52:41 EST (Tue)
From: Liz Allen <liz@brillig.umd.edu>
The mention of connecting words kind of puzzles me (and at the same
time helps me to understand the Lisp Machine loop macro). Our for
macro doesn't seem to need them (though it does use "by" and "until").
What are "let", "initially", "eachtime", "in", "on", "from", "bind", "being",
"finally", in your macro, if not connecting words, or am I totally confused?
Indeed. Furthermore, the basic syntax you gave is too basic for me to
understand the syntax of your proposal, since, for example, you didn't
say what an <iteration-spec> looked like. Furthermore, what does a
<condition-spec> do; that is, what does "when <form*>" mean? Does that
means that the first form following the "when" is tested, and the rest
are implicit-progn'ed consequents? What does "eachtime" mean and how is
it different from "do"?
It would help a lot to see an example, too. How would you translate
this into your "for" construct? If you can't deal with "until" clauses
at the end of the loop, say so and move it to the front and translate
that instead. Thanks.
(loop for a from start to end by 5
for b in list
do (do-something a b)
until (null b))
∂06-Feb-86 0659 NGALL@G.BBN.COM Re: intern
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 6 Feb 86 06:59:37 PST
Date: 6 Feb 1986 09:46-EST
Sender: NGALL@G.BBN.COM
Subject: Re: intern
From: NGALL@G.BBN.COM
To: hpfclp!diamant@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 6-Feb-86 09:46:12.NGALL>
In-Reply-To: The message of Wed, 5 Feb 86 13:03:36 pst from hpfclp!diamant@hplabs.ARPA
Date: Wed, 5 Feb 86 13:03:36 pst
From: hpfclp!diamant@hplabs.ARPA
To: hplabs!common-lisp@su-ai.ARPA
Subject: intern
On page 172 of CLtL, the verb "intern" is defined. It is stated that one
action performed is setting the home package of a symbol which doesn't already
have one. My question is: does INTERN (the function) always "intern" (the
verb). Also, are there any other functions which "intern," such as import,
for instance. Specificially, should INTERN set the home package of an
uninterned symbol?
I asked this question a while back (too bad the archives are so hard
to access!). My impression was that there was a consensus that IMPORT
is the function that is responsible for "updating" the package-slot of
an uninterned symbol (since IMPORT is the only function that can put a
SYMBOL in a package).
Guy Steele sent out a list of proposed "clarifications" a few months
ago (also in the archives). The clarification for IMPORT was: "If
symbol has no owner, its package cell is updated."
-- Nick
∂06-Feb-86 0704 sean@cadre.dsl.pittsburgh.edu Common Lisp LOOP Package
Received: from CADRE.DSL.PITTSBURGH.EDU by SU-AI.ARPA with TCP; 6 Feb 86 07:04:32 PST
Received: by PITTSBURGH.EDU (5.31/5.14)
id AA04241; Thu, 6 Feb 86 10:04:29 EST
Date: Thu, 6 Feb 86 10:04:29 EST
From: sean@cadre.dsl.pittsburgh.edu (Sean McLinden)
Message-Id: <8602061504.AA04241@PITTSBURGH.EDU>
To: Fahlman@c.cs.cmu.edu
Subject: Common Lisp LOOP Package
Cc: common-lisp@su-ai.arpa
Scott:
David Miller's Common Lisp LOOP package is available via ARPA ftp
from CADRE (PITTSBURGH.EDU, CADRE.DSL.PITTSBURGH.EDU) on the directory
./lisp using anonymous FTP login. The file is "loop.lisp"
This code has been provided by David Miller who has assured me that
it was modified from code that could be freely distributed. You are
welcome to use it. I would be interested to know of any improvement,
bug fixes, etc.
Sean
∂06-Feb-86 0828 DCP@SCRC-STONY-BROOK.ARPA eval'd macros (the other point of view)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 Feb 86 08:28:44 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 411361; Thu 6-Feb-86 11:28:22-EST
Date: Thu, 6 Feb 86 11:34 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: eval'd macros (the other point of view)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, hpfclp!diamant@HPLABS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12181103172.BABYL@C.CS.CMU.EDU>
Message-ID: <860206113432.4.DCP@NEPONSET.SCRC.Symbolics.COM>
Date: Thu, 6 Feb 1986 00:18 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In most implementations that I have seen, Compile-File lists at the end
of the file, as a sort of warning, any functions that were used but that
are not known to the compiler. A function generally becomes known
either by being present in the Lisp doing the compiling, by being
defined in a previously-compiled file, or by being defined somewhere in
the current file. Dumping this list is done at the end of a file just
so that the order of definitions within a file doesn't cause a lot of
spurious warnigns to appear. Co-recursive functions can be defined with
no problem, etc.
I don't much care whether Compile warns me about undefined functions or
not. Since Compile-File waits till the end of the file to complain
about unknown functions and special variables, it seems consistent to
keep quiet about this when compiling functions one-by-one.
If there were a compile-module function (roughly (make-system 'foo :compile))
in our system it should delay warnings until all the files have been
processed. Large and/or complex systems often make calls across files.
(We could debate the modularity of that, but let's not.)
∂06-Feb-86 0939 gls@THINK-AQUINAS.ARPA LISP standardisation
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 6 Feb 86 09:38:58 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 6 Feb 86 12:39:20 est
Date: Thu, 6 Feb 86 12:40 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: LISP standardisation
To: Fitch%cs.ucl.ac.uk@cs.ucl.ac.uk, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 5 Feb 86 17:27-EST from Fitch%cs.ucl.ac.uk@cs.ucl.ac.uk
Message-Id: <860206124034.5.GLS@THINK-DESIDERIUS.ARPA>
Thank you for your announcement to the Common Lisp mailing list
about progress on the EuLISP effort.
Would it be posssible for you (or someone else) to provide a brief
description of approximately what content is envisioned for each of
the language and programming environment levels, and what major
differences from Common Lisp are likely to develop within EuLISP?
I realize that precise statements cannot be had yet, but general
indications of the current thinking of the EuLISP committee would
be very helpful.
--Thanks,
Guy Steele
∂06-Feb-86 1318 Gregor.pa@Xerox.COM Re: loop macro
Received: from XEROX.COM by SU-AI.ARPA with TCP; 6 Feb 86 13:16:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 FEB 86 12:44:04 PST
Date: 6 Feb 86 09:01 PST
From: Gregor.pa@Xerox.COM
Subject: Re: loop macro
In-reply-to: Soley@MC.LCS.MIT.EDU's message of Wed, 5 Feb 86 17:46 EST
To: Soley@MC.LCS.MIT.EDU
To: Liz@brillig.umd.edu
cc: Gregor.pa@Xerox.COM, common-lisp@SU-AI.ARPA
Message-ID: <860206-124404-1143@Xerox>
;; Return a list of the items in list-of-items
;; which pass the test TEST.
(iterate ((item in list-of-items))
(when (test item)
(collect item)))
From Soley@MC.LCS.MIT.EDU
Parens do not a Lisp code make. This particular example, for instance,
isn't any "lispier" than the equivalent LOOP construction; the
expression "(collect item)" is CERTAINLY not a call to some new function
COLLECT, is it?
This call to COLLECT is exactly what Guy said it was, a use of a local
macro defined by a macrolet which iterate wraps around its body.
From Liz@brillig.umd.edu
I once worked with a looping macro that looked like that -- with
lots of nested parens. The main problem with it is that, when you
look at the code, you tend to think that the (when ...) up there
is a function call rather than part of some loop.
Yes, the point is that the WHEN up there is a call to the global macro
WHEN. I think that is nicer than having some special syntax in the
iteration macro that implements the same functionality WHEN already
implements.
∂06-Feb-86 1320 RPG Please remover CSTACY from this mailing list
∂06-Feb-86 1227 JNC@MC.LCS.MIT.EDU Please remover CSTACY from this mailing list
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Feb 86 12:27:26 PST
Date: Thu, 6 Feb 86 15:28:50 EST
From: "J. Noel Chiappa" <JNC@MC.LCS.MIT.EDU>
Subject: Please remover CSTACY from this mailing list
To: SPACE-REQUEST@MC.LCS.MIT.EDU, common-lisp-request@SU-AI.ARPA
cc: CENT@MC.LCS.MIT.EDU, JNC@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].810097.860206.JNC>
He is now longer an MIT employee and rarely logs in,
and his mailbnox is filling up with cruft.
JNC@MC.LCS.MIT.EDU, CStacy@MC.LCS.MIT.EDU
Mailing List Requests
Gentlemen,
I have received requests from each of you regarding the Common Lisp
mailing list, each concerned with whether or not CStacy ought to receive
said mailing list at MIT, each on the opposite side of the question from
the other. Although I would otherwise feel privileged to mediate such such
a dispute to further justice and the calm proceedings of human affairs, I
feel that my time simply does not allow me to perform this duty with quite
the attention and patience that it obviously deserves. Therefore, I would
urge you to take up the dispute with each other directly, and I pray that
no harm comes to either from my inability to act as a concilliator. Please
find below two mailing addresses, one corresponding to each disputant, and
I wish you good luck in this matter.
JNC@MC.LCS.MIT.EDU
CStacy@MC.LCS.MIT.EDU
Your most humble servant,
Richard P. Gabriel
∂06-Feb-86 1329 RPG Loop Macro
To: common-lisp@SU-AI.ARPA
During the recent discussions of loop macros there has been some
mention of the ``English-like'' syntax problem. I wonder to what extent
this is being tangled up with the issue of whitespace parsing.
Recall the language KRL (Bobrow and Winograd) in which whitespace
was considered by the reader. The idea was that if a line
was underneath andother and indented to the right, it was subordinate or
a sublist of the previous line. The examples of the Loop macro I've
seen on this mailing list seem to emphasize this:
(loop for a from start to end by 5
for b in list
do (do-something a b)
until (null b))
This indentation immediately suggests:
(loop (for a from start to end by 5)
(for b in list)
(do (do-something a b))
(until (null b)))
while this suggests lunacy (?):
(loop for a from start to end
by 5 for b
in list do (do-something a b)
until (null b))
-rpg-
∂06-Feb-86 1611 MMcM@SCRC-STONY-BROOK.ARPA LOOP again
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 Feb 86 16:11:14 PST
Received: from OWL.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 411912; Thu 6-Feb-86 19:10:38-EST
Date: Thu, 6 Feb 86 19:11 EST
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Subject: LOOP again
To: common-lisp@SU-AI.ARPA
Message-ID: <860206191124.1.MMCM@OWL.SCRC.Symbolics.COM>
Isn't there a separate SIG mailing list for this discussion?
∂06-Feb-86 1742 DLW@SCRC-STONY-BROOK.ARPA Re: loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 Feb 86 17:42:38 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 411965; Thu 6-Feb-86 20:42:00-EST
Date: Thu, 6 Feb 86 20:44 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: loop macro
To: gls@THINK-AQUINAS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860205120150.4.GLS@THINK-DESIDERIUS.ARPA>
Message-ID: <860206204441.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 5 Feb 86 12:01 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Okay, now here is a different perspective on the LOOP problem. I will play
devil's advocate here and claim that the main purpose of LOOP is to
duplicate the functionality of the sequence functions.
Your message is interesting. I remember that you advocated the
inclusion of the sequence functions partly because you wanted Lisp to
benefit from the good ideas in APL, and this message seems like a
further exposition of that idea. But I don't think it's a good argument
against LOOP. Bearing in mind that you're playing devil's advocate,
here are the problems:
(1) Your message later goes on to say "This isn't operating on
sequences, so I will render this as a DO loop." This in no way
supports the original thesis! Many simple examples of LOOP don't
operate on sequences:
(loop for x from 3 to 6
do (print x))
That a LOOP can be rendered as a DO doesn't prove much; it can also be
rendered as a PROG. I never use DO any more. Ever. LOOP is clearer
than DO in all cases, as far as I'm concerned. It certainly doesn't
prove that LOOP is being used to duplicate the functionality of the
sequence functions.
(2) It would indeed be nice if the cons-intensive examples you gave were
optimized into the equivalent iterative code. As far as I'm concerned,
it's an axiom of LOOP design/redesign that such compilers are not
widespread, if indeed they exist at all. The phrase "duplicate the
functionality" is only accurate if it implicitly means "but much
faster". Any claim that Common Lisp should not have an improved
iteration construct because it is conceivable and theoretically possible
that such a compiler might exist ignores Common Lisp's goal of living in
the real world. I agree that it would be interesting and valuable to
have such a compiler.
(3) Some people don't like having to use nameless internal functions to
do simple things. We could remove DOLIST from the language, since any
DOLIST can be trivially turned into a MAPC. But we don't. So in some
cases where iteration is being used to do something that could be done
with sequence functions, some people consider the iterative style
preferable.
[I agree with MMcM that based on the amount of interest so far, it would
be helpful to have a special-interest mailing list for this topic.]
∂07-Feb-86 0814 hoey@nrl-aic Re: loop macro
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 7 Feb 86 08:14:33 PST
Date: 7 Feb 1986 10:57:53 EST (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: loop macro
To: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Cc: Common-Lisp@su-ai.ARPA
Message-Id: <508092818/hoey@nrl-aic>
In-Reply-To: Daniel L. Weinreb's message of Wed, 5 Feb 86 1049 EST
Date: Wed, 5 Feb 86 10:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
We could add grouping without going so far as to force all clauses
to the front.
(loop (for a from 4 below 7)
(for b from 7)
(do ..body..)
(until ..pred..))
I think this might be an improvement. One problem is that we were
hoping to get rid of the "do" keyword entirely (Moon agrees with this),
but with this change, it's harder to see how to accomplish that.
Actually, people have been promised that if they don't use atoms in
their loop, it loops forever, though possibly no one has been brave
enough to use this behavior. Still, I have to agree that this stuff
looks too much like function calls, and even if "FOR" and "UNTIL" are
somehow implemented as macros, it's not the way I think of it.
These problems and DO-removal are both solved by using alternating
keywords and arguments. In the following, I don't use colons for the
LOOP keywords, since they don't follow the CL keyword standard anyway.
(DEFUN count-change (changepurse &OPTIONAL handfull)
(LOOP ;(LOOP
MEMBERS (coin changepurse) ; FOR coin IN changepurse
COUNT (howmany :END handfull) ; AS count = 0 TO handfull
(jingle) ; DO (jingle)
(IF (soup coin) ; IF (soup coin)
(COLLECT (coin :INTO sou-list); COLLECT coin INTO sou-list
(SUM (coin-value coin))) ; ELSE SUM (coin-value coin)
(IF (= howmany handfull) ; IF (= howmany handfull)
(RETURN "Too Many")) ; RETURN "Too Many"
FINALLY (drop-coins sou-list))) ; FINALLY (drop-coins sou-list))
Each keyword takes exactly one argument, which is usually a standard CL
argument list (though possibly a single argument could be rendered as
an atom). If not preceded by a keyword, the form is just evaluated.
I am particularly grossed out by the idea of having a "dangling ELSE"
in Lisp.
This is fixed here, since my IF uses Common Lisp syntax. On my braver
days, though, I would rather use
(IF (mantrap phrase)
(chant phrase)
(chant phrase)
(chant phrase)
:ELSE ((contemplate phrase)
(get-new-mantra)))
but that would break everyone's habits.
The main reason for the conditionals is so that COLLECT clauses can be
executed conditionally. (I don't know for sure whether there are other
reasons for the conditionals.) The usual proposed solution is to make
COLLECT a regular Lisp macro... a separate facility completely
orthogonal to LOOP.... After all, suppose you want to write a program
that does a double recursion down a binary tree, and collects something
as it goes?
I used this form above, but there are problems. Consider the very
useful
(LOOP MEMBERS (x elts) SUM x)
vs. (LOOP MEMBERS (x elts) COLLECT (- x)).
When elts is empty, the first should return 0 and the second NIL. Also,
LOOP needs some preamble code for every variable you COLLECT :INTO. I
guess we need declarations of the variables you are going to use for
SUM and COLLECT.
TOTAL (coin-value)
ACCUMULATE (:RETURN-VALUE)
Where :RETURN-VALUE refers to SUM or COLLECT calls that operate on the
value to be returned by LOOP. It's unfortunate that this hair has to
be added. I think ACCUMULATE :UNNAMED should be the default unless
TOTAL :UNNAMED appears. Something like this is also needed in the
standalone SUM/COLLECT you propose.
Dan Hoey
∂07-Feb-86 0944 RPG
∂07-Feb-86 0631 BRANDON@IBM-SJ.ARPA
Received: from IBM-SJ.ARPA by SU-AI.ARPA with TCP; 7 Feb 86 06:31:04 PST
Date: 7 Feb 86 09:20:12 EST
From: BRANDON@IBM-SJ.ARPA
To: rpg@sail
Dick,
Please place me on all of the mailing lists for Common LISP. I will
be the contact person for my group. Also if you have any additional
information on arpanet please send me that information also as I have
no experience with the net. Thanks again.
Brandon Cross
∂07-Feb-86 1313 Moon@SCRC-QUABBIN.ARPA loop macro
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 7 Feb 86 13:13:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 243275; Fri 7-Feb-86 16:09:10-EST
Date: Fri, 7 Feb 86 16:11 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: loop macro
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860205104933.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <860207161130.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Just to set the record straight:
Date: Wed, 5 Feb 86 10:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
....
Since I'm getting into details, I should make quite clear that I do not
speak for Moon in the matter of LOOP. Our opinions on this topic
diverge much more than they do on most other topics.
True.
One of my own strong feelings about LOOP that Moon does not share is
that we should get rid of the conditionals.
False. Dan misremembered my position here. Actually, I've believed for
several years that the conditionals in LOOP were the principal mistake in
the current design. If I were doing it over today, I would certainly use
the regular Lisp conditionals, which of course implies changes to the
theory of collection. In the real world, one might consider keeping the
conditionals just for compatibility, but frowning on their use in new code.
∂07-Feb-86 1322 Moon@SCRC-STONY-BROOK.ARPA loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Feb 86 13:21:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 412621; Fri 7-Feb-86 16:11:51-EST
Date: Fri, 7 Feb 86 16:11 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: loop macro
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860205104933.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <860207161130.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Just to set the record straight:
Date: Wed, 5 Feb 86 10:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
....
Since I'm getting into details, I should make quite clear that I do not
speak for Moon in the matter of LOOP. Our opinions on this topic
diverge much more than they do on most other topics.
True.
One of my own strong feelings about LOOP that Moon does not share is
that we should get rid of the conditionals.
False. Dan misremembered my position here. Actually, I've believed for
several years that the conditionals in LOOP were the principal mistake in
the current design. If I were doing it over today, I would certainly use
the regular Lisp conditionals, which of course implies changes to the
theory of collection. In the real world, one might consider keeping the
conditionals just for compatibility, but frowning on their use in new code.
∂07-Feb-86 1521 DDYER@SCRC-STONY-BROOK.ARPA loop macro
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Feb 86 15:21:00 PST
Received: from WHITE.SWW.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 412789; Fri 7-Feb-86 18:12:20-EST
Received: from PURPLE.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 172065; Fri 7-Feb-86 15:11:05-PST
Date: Fri, 7 Feb 86 15:11 PST
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: loop macro
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>, common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <860207161130.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860207151100.8.DDYER@PURPLE.SWW.Symbolics.COM>
Date: Fri, 7 Feb 86 16:11 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Just to set the record straight:
Date: Wed, 5 Feb 86 10:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
....
Since I'm getting into details, I should make quite clear that I do not
speak for Moon in the matter of LOOP. Our opinions on this topic
diverge much more than they do on most other topics.
True.
One of my own strong feelings about LOOP that Moon does not share is
that we should get rid of the conditionals.
False. Dan misremembered my position here. Actually, I've believed for
several years that the conditionals in LOOP were the principal mistake in
the current design. If I were doing it over today, I would certainly use
the regular Lisp conditionals, which of course implies changes to the
theory of collection. In the real world, one might consider keeping the
conditionals just for compatibility, but frowning on their use in new code.
The conditionals wouldn't be so bad if there were BEGIN and END markers for
the scope of the body. Adding BEGIN and END as loop keywords would solve
eliminate my objections to the loop conditionals.
∂08-Feb-86 2048 sean@cadre.dsl.pittsburgh.edu LOOP Macro code for Common Lisp
Received: from CADRE.DSL.PITTSBURGH.EDU by SU-AI.ARPA with TCP; 8 Feb 86 20:48:14 PST
Received: by PITTSBURGH.EDU (5.31/5.14)
id AA03004; Sat, 8 Feb 86 23:48:32 EST
Date: Sat, 8 Feb 86 23:48:32 EST
From: sean@cadre.dsl.pittsburgh.edu (Sean McLinden)
Message-Id: <8602090448.AA03004@PITTSBURGH.EDU>
To: common-lisp@su-ai.arpa
Subject: LOOP Macro code for Common Lisp
With regard to the Common Lisp compatible LOOP macro package of
which I spoke in a recent message I must apologize for what
was an inadvertant misstatement of fact. I had stated (or implied)
that the code, which was obtained from David Miller at DePaul
University, could be freely distributed. This may be incorrect.
What is true is that David Miller expressed no objection to the
distribution of his changes, and was NOT AWARE of any restrictions
on the distribution of the code from which it was derived. In no
way does this imply that the code may be distributed without
restrictions and users should be aware of this fact.
Again, my apologies for the misunderstanding.
Sean McLinden
Decision Systems Laboratory
∂10-Feb-86 1145 Gregor.pa@Xerox.COM Compiling functions which appear inside top-level forms.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Feb 86 11:45:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 FEB 86 11:33:14 PST
Date: 10 Feb 86 11:33 PST
From: Gregor.pa@Xerox.COM
Subject: Compiling functions which appear inside top-level forms.
To: Common-Lisp@SU-AI.arpa
cc: Gregor.pa@Xerox.COM
Message-ID: <860210-113314-1468@Xerox>
If the following appears as a top-level form in a file:
(let ((foo (make-foo)))
(declare (special foo))
(setf (foo-function foo) #'(lambda (x y) (+ x y)))
(store-foo-away-somewhere foo))
And I compile and load the file.
Question to implementors:
Will the function #'(lambda (x y)...) be compiled?
Will it be a lexical closure?
General question:
Would it be reasonable to require that it be compiled?
I think that this function should be compiled. I think portable
programs should be able to count on that.
...turning up burners slightly...
This seems like another instance of the general problem that thex
semantics of compile-file is not well enough defined. Maybe we should
take another stab at that problems now. Now that lots of people are
working on new ways to store programs (databases, definition-groups etc)
we can probably get some good feedback about this. If we wait until
everyone has their new "code database" stuff finished it may be too late
to settle on anything that will make old-fashioned files a tool for
distributing quality portable code.
∂10-Feb-86 1215 @MIT-REAGAN.ARPA:KWH@MIT-AI.ARPA The return of UNSPECIAL
Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 10 Feb 86 12:15:41 PST
Received: from SID.AI.MIT.EDU by MIT-REAGAN.ARPA via CHAOS with CHAOS-MAIL id 22617; Mon 10-Feb-86 15:14:00-EST
Date: Mon, 10 Feb 86 15:13 EST
From: Ken Haase <KWH@MIT-AI.ARPA>
Subject: The return of UNSPECIAL
To: common-lisp@SU-AI.ARPA
cc: KWH@MIT-AI.ARPA
Message-ID: <860210151334.2.KWH@SID.AI.MIT.EDU>
What is the status of UNSPECIAL in Common LISP? In the archives on MC I
can find references to its demise (in the Laser edition), but no
arguments as to the reasons. While it might speed up the interpreter to
not have unspecial declarations (just a guess), it would be nice to have
ASSURED special declarations....
Ken
∂10-Feb-86 1245 FAHLMAN@C.CS.CMU.EDU Compiling functions which appear inside top-level forms.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Feb 86 12:44:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 10 Feb 86 15:46:27-EST
Date: Mon, 10 Feb 1986 15:46 EST
Message-ID: <FAHLMAN.12182320708.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: Compiling functions which appear inside top-level forms.
In-reply-to: Msg of 10 Feb 1986 14:33-EST from Gregor.pa at Xerox.COM
Question to implementors:
Will the function #'(lambda (x y)...) be compiled?
In Spice Lisp, yes, this is compiled.
Will it be a lexical closure?
In this example, the question is moot since the function does not use
anything from the lexical envrionment outside of itself. But in
general, it will see the lexical environment.
General question:
Would it be reasonable to require that it be compiled?
Yes. There was a lot of discussion before the book came out about the
technique of turning random top-level forms into functions of no args
which the compiler can process normally. It then emits the definition
followed by a call to this odd function. We shouldn't require exactly
that, since some implementations would then have trouble GC-ing this
anonymous function, but we should require equivalent semantics in
judging what the compiler compiles. I don't think this is required
currently -- as you say, the description of Compile-File needs a lot of
work now.
-- Scott
∂10-Feb-86 1305 Gregor.pa@Xerox.COM Re: Compiling functions which appear inside top-level forms.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Feb 86 13:04:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 FEB 86 13:05:19 PST
Date: 10 Feb 86 13:05 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Compiling functions which appear inside top-level forms.
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
10 Feb 86 15:46 EST
To: Fahlman@C.CS.CMU.EDU
cc: Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <860210-130519-1594@Xerox>
Will it be a lexical closure?
In this example, the question is moot since the function does not use
anything from the lexical envrionment outside of itself. But in
general, it will see the lexical environment.
I should have said "Will it be a lexical closure or will it be something simpler
(if the Lisp supports compiled functions which are simpler than lexical closures
and can be funcalled faster)".
∂11-Feb-86 0811 kessler%utah-orion@utah-cs.arpa Car and Cdr of nil is nil
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 11 Feb 86 08:11:16 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA03040; Tue, 11 Feb 86 09:13:02 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA23237; Tue, 11 Feb 86 09:12:57 MST
Date: Tue, 11 Feb 86 09:12:57 MST
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8602111612.AA23237@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Car and Cdr of nil is nil
Does anyone recall where this feature comes from and the history behind why
it was done??
Thanks.
Bob.
∂11-Feb-86 0915 FAHLMAN@C.CS.CMU.EDU Car and Cdr of nil is nil
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Feb 86 09:15:13 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 11 Feb 86 12:16:56-EST
Date: Tue, 11 Feb 1986 12:16 EST
Message-ID: <FAHLMAN.12182544718.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: kessler%utah-orion@λutah-cs.arpa (Robert Kessler)λ
Cc: common-lisp@SU-AI.ARPA
Subject: Car and Cdr of nil is nil
In-reply-to: Msg of 11 Feb 1986 11:12-EST from kessler%utah-orion at utah-cs.arpa (Robert Kessler)
This rather controversial feature was adopted in Maclisp after some
people saw it in Interlisp. I'm not sure if the Maclisp people thought
it was a good idea, or if they just thought they'd better be compatible
for ease in porting programs. If a program relies on this feature, it
is often very hard to get it running in a Lisp that doesn't have it.
I'll let the Interlisp people describe the genesis of this feature, but
it's clear what the arguments pro and con are. On the plus side, this
allows you to use lists as data structures and to truncate any all-NIL
branches without having to put checks for this into the accessors. So
the programmer (or structure-writing macro) can just write CADDDR, and
get NIL if the data structure is (FOO (SOME LIST)). On the minus side,
this feature really messes up the type hierarchy and it can create nasty
problems for Lisp implementors on stock hardware -- a lot of trickery is
required if you want CAR and CDR to operate properly and quickly without
having to check for NIL as a special case.
-- Scott
∂11-Feb-86 0922 FAHLMAN@C.CS.CMU.EDU Compiling functions which appear inside top-level forms.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Feb 86 09:18:33 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 11 Feb 86 12:19:44-EST
Date: Tue, 11 Feb 1986 12:19 EST
Message-ID: <FAHLMAN.12182545232.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: Compiling functions which appear inside top-level forms.
In-reply-to: Msg of 10 Feb 1986 16:05-EST from Gregor.pa at Xerox.COM
Again speaking only for Spice Lisp, I believe that our compiler does not
create any extra hair in compiled code for getting at lexical variables
unless it is actually needed. Simply compiling somethign in a non-null
lexical environment will not cost you anything.
-- Scott
∂11-Feb-86 0941 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU code density as a function of elegance
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Feb 86 09:40:58 PST
Date: Tue 11 Feb 86 12:15:55-EST
From: "Rodney A. Brooks" <BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: code density as a function of elegance
To: common-lisp@SU-AI.ARPA
Message-ID: <12182544551.69.BROOKS@OZ.AI.MIT.EDU>
Re: Bob Kessler's question.
(I don't think this made it to the CL list previously--apologies if
it did.)
A SHORT BALLAD DEDICATED TO THE GROWTH OF PROGRAMS
==================================================
by
Ashwin Ram
This is a tale of a sorry quest
To master pure code at the T guru's behest
I enrolled in a class that appealing did seem
For it promised to teach fine things like T3 and Scheme
The first day went fine; we learned of cells
And symbols and lists and functions as well
Lisp I had mastered and excited was I
For to master T3 my hackstincts did cry
I sailed through the first week with no problems at all
And I even said "closure" instead of "function call"
Then said the master that ready were we
To start real hacking instead of simple theory
Will you, said he, write me a function please
That in lists would associate values with keys
I went home and turned on my trusty Apollo
And wrote a function whose definition follows:
(cdr (assq key a-list))
A one-liner I thought, fool that I was
Just two simple calls without a COND clause
But when I tried this function to run
CDR didn't think that NIL was much fun
So I tried again like the good King of yore
And of code I easily generated some more:
(cond ((assq key a-list) => cdr))
It got longer but purer, and it wasn't too bad
But then COND ran out and that was quite sad
Well, that isn't hard to fix, I was told
Just write some more code, my son, be bold
Being young, not even a moment did I pause
I stifled my instincts and added a clause
(cond ((assq key a-list) => cdr)
(else nil))
Sometimes this worked and sometimes it broke
I debugged and prayed and even had a stroke
Many a guru tried valiantly to help
But undefined datums their efforts did squelch.
I returneth once more to the great sage of T
For no way out of the dilemma I could see
He said it was easy -- more lines must I fill
with code, for FALSE was no longer NIL.
(let ((val (assq key a-list)))
(cond (val (cdr val))
(else nil)))
You'd think by now I might be nearing the end
Of my ballad which seems bad things to portend
You'd think that we could all go home scot-free
But COND eschewed VAL; it wanted #T
So I went back to the master and appealed once again
I said, pardon me, but now I'm really insane
He said, no you're not really going out of your head
Instead of just VAL, you must use NOT NULL instead
(let ((val (assq key a-list)))
(cond ((not (null? val)) (cdr val))
(else nil)))
My song is over and I'm going home to bed
With this ineffable feeling that I've been misled
And just in case my point you have missed
Somehow I preferred (CDR (ASSQ KEY A-LIST))
-------
∂11-Feb-86 1122 Bobrow.pa@Xerox.COM Re: Car and Cdr of nil is nil
Received: from XEROX.COM by SU-AI.ARPA with TCP; 11 Feb 86 11:21:55 PST
Received: from Salvador.ms by ArpaGateway.ms ; 11 FEB 86 11:17:30 PST
Date: 11 Feb 86 11:02 PST
From: Bobrow.pa@Xerox.COM
Subject: Re: Car and Cdr of nil is nil
In-reply-to: kessler%utah-orion@utah-cs.arpa (Robert Kessler)'s message
of Tue, 11 Feb 86 09:12:57 MST
To: kessler%utah-orion@utah-cs.arpa
cc: common-lisp@su-ai.arpa
Message-ID: <860211-111730-1394@Xerox>
This was a feature introduced in BBN Lisp around 1968 to allow one to
access, say, the fourth element of a list without checking if the list
was that long. It is a useful, though terrible, pun. For very small
machines as we were on, saving the few cons cells at the end of a list
was important. And after all, one might say, the REST of an empty list
is still empty. ...
∂11-Feb-86 1228 liz@brillig.umd.edu Re: loop macro
Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 11 Feb 86 12:28:22 PST
Received: by brillig.umd.edu (5.9/4.7)
id AA09433; Tue, 11 Feb 86 15:26:29 EST
Message-Id: <8602112026.AA09433@brillig.umd.edu>
To: dlw@scrc-quabbin.ARPA
Cc: bsg@scrc-stony-brook.ARPA, common-lisp@su-ai.ARPA
Subject: Re: loop macro
In-Reply-To: Your message of Thu, 6 Feb 86 08:16 EST.
<860206081637.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 11 Feb 86 15:26:28 -0500
From: Liz Allen <liz@brillig.umd.edu>
I guess in an effort to be concise, I didn't give enough information
about out for macro to be clear...
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
What are "let", "initially", "eachtime", "in", "on",
"from", "bind", "being", "finally", in your macro, if
not connecting words, or am I totally confused?
It seemed to me that the Lisp Machine loop macro uses key words (and I
don't mean : words) not only to introduce loop clauses but also to connect
clauses in some sense (eg "and", "whereas", etc). What I was trying
to demonstrate was that it's possible to have a loop macro with much
simpler syntax -- each clause is independent and even equal in some
sense in our for macro.
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Indeed. Furthermore, the basic syntax you gave is too
basic for me to understand the syntax of your proposal,
since, for example, you didn't say what an <iteration-spec>
looked like. Furthermore, what does a <condition-spec>
do; that is, what does "when <form*>" mean? Does that
means that the first form following the "when" is tested,
and the rest are implicit-progn'ed consequents? What does
"eachtime" mean and how is it different from "do"?
Let me answer specifically here and then give examples and a fuller
syntax below and see if I can make all this clear... It's not
really that complicated, but... (If you don't get this first part
the first time you read it, skip to the examples and syntax and
then go back and read the first stuff again. I'm trying to put
the most interesting stuff at the top of this letter...)
An <iteration-spec> can be anything like:
x in list
y on list
i from 1 to n by 2
Even though these clauses have key words in them, the clauses have
definite boundaries -- each clause still stands alone.
A <condition-spec>, when <form>* translates into when (progn <form>*)
and the value of the last <form> given is the value tested. Using
multiple forms in <condition-spec>'s is probably not the best programming
approach, but before we had an eachtime clause, it was sometimes
necessary. That brings me to the next question.
"Eachtime" clauses are executed every time through the loop before
any of the conditions ("while", "until", "when", "unless", or even
conditions generated by things like "x in list") are done. The
"do" clause is only done after those tests and when appropriate --
not every time through the loop. This is suggested by the usual
ordering of the clauses in the for. Remember that we don't have
multiple bodies.
It would help a lot to see an example, too. How would you
translate this into your "for" construct? If you can't
deal with "until" clauses at the end of the loop, say so
and move it to the front and translate that instead.
Thanks.
(loop for a from start to end by 5
for b in list
do (do-something a b)
until (null b))
That would translate to:
(for a from start to end by 5
b in list
eachtime (do-something a b)
until (null b))
It's unusual for in that there's no body, but the default is "do
nil". What couldn't be done is if that original do up there was
a collect (or almost any other body keyword) instead. Then the
for macro would have to be changed so that:
(for a from start to end by 5
b in list
collect (do-something a b)
until (null b))
expanded to something like:
(let ((g0001 list))
(do (($$val)
(a start (plus a 5))
(b (car g0001) (car (setq g0001 (cdr g0001)))))
((or (greaterp a end) (null g0001)) (nreverse $$val))
(setq $$val (cons (do-something a b) $$val))
(cond ((null b) (return (nreverse $$val))))))
Currently, all the termination conditions are placed in the do
termination. It could be awkward to have to repeat the value to
be returned if it got complicated (eg multiple values). The best
alternative would be to move that part out of the do, but then the
finally clause could not reference the do variables.
With that, let me give some more examples and a full syntax for the
current for macro. These are taken from the Univ of Maryland Franz
Lisp Environment TR (authored by myself, Randy Trigg and Rich Wood).
; This is like (mapc 'patom '(a b c))
(for x in '(a b c)
do (msg x)) ; print x to standard out with no terpr
abcnil
; This is like (mapcar 'cons '(a b c) '(d e f)).
(for x in '(a b c)
y in '(d e f)
collect (cons x y))
((a . d) (b . e) (c . f))
; This is like
; (mapcan (function (lambda (x) (list x 3))) '(a b c)).
(for x in '(a b c)
join (list x 3))
(a 3 b 3 c 3)
; Example of "sum" as well as "when".
(for x in '(a b 3 4 c 5)
when (numberp x)
sum x)
12
; Example of "destructuring" with "in".
(for (x (y) . z) in '((a (b) c) (d (e) . f) (g (h) i j))
do (msg x B y B z N)) ; the B's say print blanks and the N
; says to do terpr (msg is from Franz
; and case is significant there)
a b (c)
d e f
g h (i j)
nil
; Example of "thereis" keyword. Notice that the value of the last expression
; is the one used by "thereis".
(for x in '(a b 3 4 c 5)
thereis (msg x N)
(numberp x))
a
b
3
t
; Shows off "until", "count", and "finally". Notice the reference to "$$val"
; (contains the result of the for loop) in the "finally" clause.
(for let (a 3) b
until (eq (setq a (add1 a)) 6)
count (msg a N)
finally (list $$val a))
4
5
(2 6)
; Notice here that "bind" variables can reference "let" variables.
(for let (a 3)
bind (b a (add1 b))
while (lessp b 6)
sum (msg (cons a b) N)
b)
(3 . 3)
(3 . 4)
(3 . 5)
12
; Notice the use of "return" to force the loop to execute only once and the
; value of the variable "a" that the "initially" clause sees.
(for let (a 1)
initially (msg a N)
x in '(h i j)
bind (b a) (a 4) (c 1 (return $$val))
collect (list a b c x))
1
((4 1 1 h))
; Example of "last". Causes the value of the last body executed to be returned.
(for x in '(1 2 3)
while (lessp x 3)
unless (onep x)
last x)
2
; Examples of "tcollect" and "tjoin" -- they are like "collect" and "join"
; except they return tconc cells.
(for x in '(a b c)
tcollect x)
((a b c) c)
(for x in '(a b c)
tjoin (list x x))
((a a b b c c) c)
; Some examples of "from" and "fromd" - notice that both "to" and "by" are
; optional.
(for n from 0 to 2
collect n)
(0 1 2)
(for n fromd 0 by 2
x in '(a b c)
collect n)
(0 -2 -4)
; Example of "being" -- rebinds x on each iteration
(for being (x 13)
n from 0 to 1
do (msg x N)
(setq x 14))
13
13
nil
; Examples of "eachtime". Watch out! It may execute more often than expected.
(for x in nil
eachtime (msg 'hi N)
collect x)
hi
nil
(for n from 0 to 1
eachtime (msg n N)
collect n)
0
1
2
(0 1)
; Example of "quit" -- allows only one execution of the body.
(for n from 0 to 13
when (greaterp n 6)
quit n)
7
Those should give you a pretty good feel for the macro. Now for
the full syntax.
First, the easiest way to view the syntax is as (for <clause>*)
where <clause> is any of the things you see down below. The order
in which the various clauses appear below is more intuitive (they're
in the order that they will be executed) than strictly necessary.
(I'm expanding on what I gave in earlier mail; the length will give
you a clue as to why I didn't give all this then...) "[ ... ]"
means something is optional, "[ ... ]*" or " ... *" means something
can appear 0 or more times, and " ... +" means something should
appear 1 or more times.
(for [ let <let-var>+ ]* ; <let-var> is <var> or (<var> <init>)
[ initially <form>+ ]
[ <iteration-spec>+ ]* ; in, on, from, bind, being, etc
[ eachtime <form>+ ]*
[ <termination-spec>* ]* ; while <form>+ or until <form>+
[ <condition-spec>* ]* ; when <form>+ or unless <form>+
[ <body-key> <form>+ ] ; <body-key> is do, collect, etc
[ finally <form>+ ] )
Wherever you see <form>+, if more than one <form> really does
appear, then a progn is put around the whole thing and the last
value is the one that is used. Note that multiple let's turn into
successive let's on the outside so that later let's may reference
vars in earlier ones. Forms appearing in the initially clause and
the <iteration-spec>'s may also reference any let variables. An
<iteration-spec> can be any of the following:
<var> in <form>
<var> on <form>
<var> from <start> [ to <end> ] [ by <step> ]
; <step> defaults to 1
<var> fromd <start> [ to <end> ] [ by <step> ]
; subtracts <step> each time
bind <bind-var>+
; <bind-var> can be <var> or (<var> [ <init> [ <next> ] ]),
; the latter is like a do variable clause
being (<var> <value>)+
; <var> is set to <value> every time, like
; bind (<var> <value> <value>)
Each of the <var>'s becomes a do iteration <var>.
Throughout the for, you can use $$val to reference the value (maybe
just so far) of the for.
The table below explains what the <body-key>'s may be and the
corresponding value for the for where x1, ... xi, ... xn are the
values of the clause (last <form> in the clause) for the 1st, ...
ith, ... nth execution of the loop.
<body-key> $$val
do nil
collect (list x1 ... xi ... xn)
join (nconc x1 ... xi ... xn)
sum (plus x1 ... xi ... xn)
count n
always (and x1 ... xi ... xn)
never (and (not x1) ... (not xi) ... (not xn))
thereis (or x1 ... xi ... xn)
last xn
tcollect like collect only a tconc cell
tjoin like join only a tconc cell
quit x1 (only executes body once), if body never
executes, then nil
Note that always, never and thereis shortcut if possible -- eg
always will quit and return nil on the first null xi. They also
do not execute the finally clause if they quit early.
Hope all this makes sense...
-Liz
∂11-Feb-86 1234 hpfclp!diamant@hplabs.ARPA Re: intern
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 11 Feb 86 12:34:21 PST
Received: by hplabs.ARPA ; Tue, 11 Feb 86 12:33:45 pst
Date: Tue, 11 Feb 86 12:33:45 pst
From: hpfclp!diamant@hplabs.ARPA
To: hplabs!common-lisp@su-ai.ARPA
Subject: Re: intern
From: hplabs!NGALL@G.BBN.COM
My question is: does INTERN (the function) always "intern" (the
verb). Also, are there any other functions which "intern," such
as import, for instance. Specificially, should INTERN set the
home package of an uninterned symbol?
I asked this question a while back (too bad the archives are so hard
to access!). My impression was that there was a consensus that IMPORT
is the function that is responsible for "updating" the package-slot of
an uninterned symbol (since IMPORT is the only function that can put a
SYMBOL in a package).
Guy Steele sent out a list of proposed "clarifications" a few months
ago (also in the archives). The clarification for IMPORT was: "If
symbol has no owner, its package cell is updated."
-- Nick
Thanks for the clarification on IMPORT. I did have a copy of the
clarifications, but hadn't looked them over carefully enough. I am
certainly satisfied by the new definition of IMPORT, but something
still bothers me about INTERN. As the reason for having import be
the only function responsible for updating the package slot, you claim that
IMPORT is the only function that can put a SYMBOL in a package. By this,
do you mean an already existing symbol, or any symbol? Obviously, if
I type (intern "FOO"), I will put the symbol FOO in the current package (if
it wasn't already available). If you mean an already existing symbol,
isn't that equivalent to the question I already asked? I'm not trying
to be picky -- I just don't understand the motivation for restricting
INTERN from setting the home package. On page 172, CLtL says (for the
function INTERN): "If the symbol previously was unowned, then the package
it is being interned in becomes its owner (home package); but if the symbol
was previously owned by another package, the other package continues to
own the symbol." To me, that seems to strongly suggest that INTERN would
have to set the home package on a symbol which doesn't CURRENTLY have a
home package. As I said before, this creates a problem for the definition
of FIND-SYMBOL since it is defined to be identical to INTERN except that
it can't create a new symbol. Consider:
(let ((x (intern "FOO")))
(import x (find-package "BAR"))
(unintern x)
(find-symbol "FOO" (find-package "BAR")))
;; the defn. in CLtL would imply that x would now be homed in BAR.
John Diamant
Fort Collins Systems Division UUCP: {ihnp4,hplabs}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs
Fort Collins, CO
∂11-Feb-86 1443 masinter.pa@Xerox.COM Re: Car and Cdr of nil is nil
Received: from XEROX.COM by SU-AI.ARPA with TCP; 11 Feb 86 14:40:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 FEB 86 13:59:48 PST
Date: 11 Feb 86 13:58 PST
From: masinter.pa@Xerox.COM
Subject: Re: Car and Cdr of nil is nil
In-reply-to: Fahlman%C.CS.CMU.EDU:ARPA:Xerox's message of 11 Feb 86
09:41
To: Common-Lisp@su-ai.ARPA
Message-ID: <860211-135948-1619@Xerox>
The use of (CAR NIL) = NIL predates 1971, which is the earliest BBN-Lisp
manual I have.
The operation of CAR and CDR on NIL is somewhat independent of the use
of NIL as a symbol, the empty list, and false. ("this feature really
messes up the type hierarchy"), in that, even if one left CAR and CDR
undefined or "is an error" on NIL, one might still use NIL = () = (NOT
T).
As for "nasty problems for Lisp implementors on stock hardware", this
was a nasty problem 10 years ago, but the technology for handling it,
even on stock hardware, is well in hand. The nastiness for stock
hardware is keeping (setf (car 3215) t) from crashing your system.
∂11-Feb-86 2008 HEDRICK@RED.RUTGERS.EDU problem with (CAR NIL) = NIL
Received: from RED.RUTGERS.EDU by SU-AI.ARPA with TCP; 11 Feb 86 20:08:41 PST
Date: 11 Feb 86 23:08:16 EST
From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
Subject: problem with (CAR NIL) = NIL
To: common-lisp@SU-AI.ARPA
Message-ID: <12182663309.38.HEDRICK@RED.RUTGERS.EDU>
The reason I don't like (CAR NIL) = NIL is that it causes many program
errors to be undetected. I always prefered to have NIL set up so
that attempts to follow its CAR or CDR resulted in illegal memory
references. It is easy enough to make the CAR and CDR be NIL on
most machines. It just requires monkeying around with the
representations so that this falls out. E.g. on the DEC-20,
NIL is 0, and we arrange that locations 0 and 1 always contain
0. This requires some care, and functions that access property
lists must check specifically for NIL, but we don't think anyone
notices a performance change due to this hack. What they do notice
is that buggy programs take longer to debug than they should.
-------
∂12-Feb-86 0708 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: loop macro
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 12 Feb 86 07:07:42 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a001193; 12 Feb 86 14:55 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Wed, 12 Feb 86 14:54:08 GMT
Message-Id: <Wed Feb 12 14:54:08 1986 @ aiva.edinburgh.ac.uk>
To: dlw@scrc-quabbin.arpa, liz@brillig.umd.edu
Subject: Re: loop macro
Cc: bsg@scrc-stony-brook.arpa, common-lisp@su-ai.arpa
Re Maryland loop macro: one thing is still unclear to me: are the iteration
variables always stepped in parallel (a la DO)? Is there any way to have
it done sequentially (DO*)? One reason for linking words in ZetaLoop is
to distinguish these cases.
∂12-Feb-86 0757 NGALL@G.BBN.COM Re: intern
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 12 Feb 86 07:56:46 PST
Date: 12 Feb 1986 10:54-EST
Sender: NGALL@G.BBN.COM
Subject: Re: intern
From: NGALL@G.BBN.COM
To: hpfclp!diamant@HPLABS.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]12-Feb-86 10:54:19.NGALL>
In-Reply-To: The message of Tue, 11 Feb 86 12:33:45 pst from hpfclp!diamant@hplabs.ARPA
Date: Tue, 11 Feb 86 12:33:45 pst
From: hpfclp!diamant@hplabs.ARPA
To: hplabs!common-lisp@su-ai.ARPA
Subject: Re: intern
From: hplabs!NGALL@G.BBN.COM
My question is: does INTERN (the function) always "intern" (the
verb). Also, are there any other functions which "intern," such
as import, for instance. Specificially, should INTERN set the
home package of an uninterned symbol?
I asked this question a while back (too bad the archives are so hard
to access!). My impression was that there was a consensus that IMPORT
is the function that is responsible for "updating" the package-slot of
an uninterned symbol (since IMPORT is the only function that can put a
SYMBOL in a package).
Guy Steele sent out a list of proposed "clarifications" a few months
ago (also in the archives). The clarification for IMPORT was: "If
symbol has no owner, its package cell is updated."
-- Nick
...
Thanks for the clarification on IMPORT. I did have a copy of the
clarifications, but hadn't looked them over carefully enough. I am
certainly satisfied by the new definition of IMPORT, but something
still bothers me about INTERN. As the reason for having import be
the only function responsible for updating the package slot, you claim that
IMPORT is the only function that can put a SYMBOL in a package. By this,
do you mean an already existing symbol, or any symbol? Obviously, if
An already existing symbol.
I type (intern "FOO"), I will put the symbol FOO in the current package (if
it wasn't already available). If you mean an already existing symbol,
isn't that equivalent to the question I already asked?
I'm not sure wwhich question you are refering to.
I'm not trying
to be picky -- I just don't understand the motivation for restricting
INTERN from setting the home package. On page 172, CLtL says (for the
Neither do I. (And I don't think you're being picky, keep the
comments coming!)
function INTERN): "If the symbol previously was unowned, then the package
it is being interned in becomes its owner (home package); but if the symbol
was previously owned by another package, the other package continues to
own the symbol." To me, that seems to strongly suggest that INTERN would
have to set the home package on a symbol which doesn't CURRENTLY have a
home package. As I said before, this creates a problem for the definition
Unfortunately, most implementors seem to have ignored this passage.
of FIND-SYMBOL since it is defined to be identical to INTERN except that
it can't create a new symbol. Consider:
(let ((x (intern "FOO")))
(import x (find-package "BAR"))
(unintern x)
(find-symbol "FOO" (find-package "BAR")))
;; the defn. in CLtL would imply that x would now be homed in BAR.
In my first reply, I forgot about good old UNINTERN, which can make an
interned symbol homeless (as in your example). So I was making the
point that if one "fixed" import, one could never get homeless
interned symbols. Wrong.
I think the attitude at the time was that IMPORTing a homeless symbol
(e.g., a GENSYMed symbol) was the only "straightforward" way that an
interned symbol could be left homeless, i.e., it is the only way
"novice" CL user's could "easily" cause such an inconsistency. The
case of UNINTERN a symbol from its home package when it is also
present in other packages, was considered a pathological case (it is
even mentioned in the description of UNINTERN), and not worth the
trouble of having INTERN deal with. So the passage on 172 was to be
removed (Guy, this is not in your list of clarifications.) and the
wording for IMPORT changed as I mentioned previously.
As far as FIND-SYMBOL is concerned, I think the "identical behavior"
wording was used because the passage on pg. 172 as overlooked. To me,
the idea behind find-symbol is that it is identical to INTERN except
that it does not cause ANY side-effects (incl. fixing the package
slot).
What I would like to see is the following:
1. Leave the stipulation on page 172 that INTERN fix-up the package
slot of an interned symbol.
2. Refer to pg. 172 in the def. of INTERN.
3. Make IMPORT also fix up the package slot.
4. In UNITERN, after warning about homeless interned symbols, cf.
IMPORT for fixing things up.
5. Make clear that FIND-SYMBOL has NO SIDE EFFECTS. And point out
that it is the only way of mapping a name to a homeless interned
symbol.
How 'bout it?!
∂12-Feb-86 1951 FAHLMAN@C.CS.CMU.EDU The return of UNSPECIAL
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Feb 86 19:51:04 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 12 Feb 86 22:52:34-EST
Date: Wed, 12 Feb 1986 22:52 EST
Message-ID: <FAHLMAN.12182922583.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Ken Haase <KWH@AI.AI.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: The return of UNSPECIAL
In-reply-to: Msg of 10 Feb 1986 15:13-EST from Ken Haase <KWH at MIT-AI.ARPA>
There is currently no UNSPECIAL or LEXICAL declaration in Common Lisp.
I think this was done because we thought it was not needed and that it
added additional complexity to the language. A lot of people ahve
complained about this, and I think it will probably be put back in
someday.
-- Scott